Rikki

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Reminder: this blog covers the technical details of 4.0's programming. For details on 4.0's features, follow our main blog.

Reviewing controllers

Some time ago, I blogged about the javascript framework we've built for IPS4. In it, I covered the most important component: controllers. To recap, a controller is a special object within the framework, and is applied on specific elements. That element is the controller's scope, and the controller works on it to provide its functionality. For example, a simple controller might look like this:

ips.controller.register('core.global.core.example', { initialize: function () { this.on( 'click', this.showAlert ); }, showAlert: function (e) { alert( "This button's text is: " + this.scope.html() ); } });
It would be used on an element like so:

<button data-controller='core.global.core.example'>Click me</button>
Here we're registering core.global.core.example as a controller. This represents the controller path - it's in the format app.module.group.controllerName. Though it seems longwinded, this allows IPS4 to dynamically load controllers on-demand, rather than loading them all when the page is loaded. In the initialize method (called automatically), we set up an event handler for a click. When the element is clicked, you'd see an alert saying "This button's text is: Click me".

So, that's how controllers work. Almost all page behavior in IPS4 is handled through controllers. But how would you change a method in an existing controller, say if you were writing an addon, or if you had two controllers that were fairly similar, and wanted to provide a base controller they both shared?

Mixins

To enable that, we have mixins. Mixins allow you to specify functions which are inherited by objects - in this case, our controller objects. This means, using mixins we can add new functions to a controller without needing to edit the controller itself.

A mixin is defined like so:

ips.controller.mixin('addAnotherMethod', 'core.global.core.example', true, function () { this.anotherMethod = function () { alert('Inside anotherMethod'); }; });
The ips.controller.mixin method takes up to 4 parameters:

ips.controller.mixin( name, controller, automaticallyExtend, fnDefinition )
name: Name to identify this mixin
controller: The controller this mixin extends
automaticallyExtend: [optional, default false] Does this mixin automatically extend the controller (more on that below)
fnDetinition: The function definition applied to the controller

In this example, our mixin adds a method named anotherMethod to our core.global.core.example controller shown earlier.

Let's talk more about the automaticallyExtend parameter. Mixins can be applied to controllers in one of two ways - either automatically on a global basis, or manually on a case-by-case basis. Mixins are manually specified like so:

<button data-controller='core.global.core.example( addAnotherMethod )'>Click me</button>
This means the mixin is used on this element - but another element using core.global.core.example wouldn't get it. This is useful when you're building your own apps or addons; you can write simple controllers that implement base functionality, then extend them with functionality for specific cases by specifying the mixin name in your HTML. We use this ourselves - for example, we have a base table controller that handles sorting, filtering and so forth. We then have a mixin for AdminCP tables, and a mixin for front-end tables, which add functionality specific to those areas, reducing code duplication.

If you're extending an IPS controller in an IPS app, though, modifying the HTML isn't typically an option. Instead, you can specify the mixin as global, and it will be applied to all elements where that controller is used. This means you can write your own mixins that work with our default controllers without having to touch our controller code (and that's a good thing).

Advice

So that shows how to add new methods to a controller. But what if you want to work with the methods that already exist in the controller? In the above example you'd only be able to overwrite an existing method - certainly not ideal, because 1) you would break any other mixins using the default method, 2) if we made an update to a method in a later release, your mixin would break it.

To facilitate working with existing controller methods, we're using a model called advice. This adds three special methods to a mixin: before, after and around. These let you 'hook into' existing methods and provide additional code for them. Let's rewrite our example mixin from above to take advantage of it:

ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.before('showAlert', function () { this.scope.css({ background: 'red' }); }; });
Here, I'm using the before method. I'm hooking into showAlert method (from the controller), and changing the background color of the scope element. So what happens when the link is clicked? First the background changes to red, and then an alert box is shown. We've added the background changing functionality without needing to edit the controller at all. Here's two other ways of doing the same thing, using the other two special methods:

ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.after('showAlert', function () { this.scope.css({ background: 'red' }); }; this.around('showAlert', function (origFn) { this.scope.css({ background: 'red' }); origFn(); }; });
The after method is fairly self-evident. With the around method, the original function is passed in as an argument, allowing you to determine when it is executed by your mixin.

All three of these methods will stack, so multiple mixins can hook into the same method, and they'll be executed in order, each receiving the previous.

Conclusion

I hope this introduction to mixins proves useful to developers; it shows how our core app controllers can be extended in a non-destructive way, but also how your own apps can use the mixin functionality to create an inheritance model to make your life easier.

Javascript in IPS4 makes extensive use of custom events, so the preferred way of adding new functionality is to listen for appropriate events and act on them - but the mixin support described above provides a mechanism by which you can adapt existing event handlers.

When your customers buy or use your products, they will have many questions. They may have issues using the product, or they may have requests for future versions based on their needs.
Managing and responding to those questions and requests quickly increases conversion, satisfaction and the likelihood or purchasing again.
The statistics back this up.

There is no doubt that unless you have a support community for your brand,  you are not delivering the best experience for your customers and risk losing them to competitors that do.
Building a support community around your product or service will positively drive your business across all departments from product development through sales and into customer support.
Let's break it down and look at the key benefits for each department.
Customer Service
Encouraging your customers to visit your support community is the simplest way to reduce the cost of supporting your product or service. Creating a self-help culture allows other more experienced customers to offer assistance and troubleshoot any problems they have.
73% of customers fall in love with a brand because of friendly customer service representatives.**
Quite often, new customers encounter the same issues that would flood customer support if they were all channelled to your support desk. For example, consider a company that produces an internet-enabled smart device. Less technically savvy customers will likely contact support to troubleshoot initial connectivity issues which can quickly be resolved by peers in the support community.
These questions and answers form a crowdsourced knowledge base that will allow customers to help themselves without any intervention from your team. Furthermore, these questions will feature in external search results, driving more traffic to your site.

Sales
The primary purpose of your community may have initially been to help support your customers, but it quickly becomes a valuable resource to help drive sales.
Your support community will be a relaxed place where customers talk to each other honestly and openly. They will be less inhibited than they would if they were talking to your sales agents.
Customers might be discussing a need for more functionality that you have in another product or service. Your sales team can move these conversations from the community to your CRM to curate new sales leads.
72% of customers will tell 6 people or more if they have a satisfying experience. - Esteban Kolsky
Customers that have had positive interactions with their peers and members of your support team will become advocates for your brand. They will help sell your product over social media and among their friend circles. Given than 90% of customers are influenced by a positive review when buying a product*, having brand advocates is critical to your growth.

Marketing
There are several costly routes to learning about your customers and their wants and needs. You can conduct external surveys, or pay for research groups to look at your products and offer feedback.
56% of customers don't mind sharing their personal information in exchange for better service.**
The most effective method is to look at your community.
Your customers will be posting their thoughts daily. They'll tell you exactly how they use your products, offering you valuable insight into the problems they are solving with your product. This information should be used as the basis of new marketing campaigns.

Project Development
Your support community is a direct line to your customers. You no longer need to use external tools and services to determine which features you should add next. You'll be told directly!
55% of customers are willing to spend more money with a company that guarantees them a satisfying experience.**
You'll find that some feature requests bubble up regularly. These are the ones you will want to move to your product roadmap.
Invision Community allows you to segment your community into private areas for beta testing. Your developers can interact with this group to work directly with your customers to shape new functionality.
Harnessing analytical data will inform development decisions. Invision Community can track keywords in user-generated content. If you have released a new feature, you can track how often it is mentioned in conversations to monitor its uptake.
52% of customers believe that companies need to take action on their feedback.*

Setting up your Invision Community
Now we've looked at the compelling reasons you should create a support community around your products, let's take a look at how to set up your Invision Community.
Support Desk
Invision Community has a fully-featured built in support desk functionality. Commerce has all the features you need, including multiple support desk categories, reply by email, pre-written reply templates and private notes.

 
However, if you already use another support desk such as Zendesk then our API tools mean that Invision Community can integrate with your existing support flow seamlessly.
Keyword Tracking
Invision Community allows you to track how often specific words or phrases. This is useful to monitor which of your products are trending or monitoring uptake on new features.
To set this up, visit the Statistics section of the Admin CP.
Question and Answers
To formalize a support or ideation area within your support community, Invision Community offers a Question and Answer forum type.
Question and Answer forum types allow your members to post questions and enable other members to upvote the questions and replies. Your support team can also flag specific responses as the "best answer" which turns historical questions into a crowdsourced knowledge base.
Showcasing Great Content
Invision Community has several tools to highlight great customer-created content. You can pin topics, and feature specific replies within those topics.
You can also convert posts into new articles within a formal knowledge base or blog to further help your customers find the right answers to their questions.
Extensibility
Invision Community has OAuth and a REST API out of the box. This means it's trivial to extend Invision Community to work within your existing flows. Integrate Invision Community to your SalesForce CRM and Zendesk support systems seamlessly.
Create a federated search to integrate your external knowledge base with client-generated knowledge.
The options are limitless, and we can take care of any custom integrations for you.
If you have any questions, please let me know below, or contact us to see how we can help you harness the power of community for your business.
* https://www.customerthermometer.com/customer-service/customer-service-and-satisfaction-statistics-for-2019/
** https://www.qminder.com/customer-service-statistics/

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need
 
Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field
 
Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record
 
Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}  
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Reminder: this blog covers the technical details of 4.0's programming. For details on 4.0's features, follow our main blog.

Reviewing controllers

Some time ago, I blogged about the javascript framework we've built for IPS4. In it, I covered the most important component: controllers. To recap, a controller is a special object within the framework, and is applied on specific elements. That element is the controller's scope, and the controller works on it to provide its functionality. For example, a simple controller might look like this:

ips.controller.register('core.global.core.example', { initialize: function () { this.on( 'click', this.showAlert ); }, showAlert: function (e) { alert( "This button's text is: " + this.scope.html() ); } });
It would be used on an element like so:

<button data-controller='core.global.core.example'>Click me</button>
Here we're registering core.global.core.example as a controller. This represents the controller path - it's in the format app.module.group.controllerName. Though it seems longwinded, this allows IPS4 to dynamically load controllers on-demand, rather than loading them all when the page is loaded. In the initialize method (called automatically), we set up an event handler for a click. When the element is clicked, you'd see an alert saying "This button's text is: Click me".

So, that's how controllers work. Almost all page behavior in IPS4 is handled through controllers. But how would you change a method in an existing controller, say if you were writing an addon, or if you had two controllers that were fairly similar, and wanted to provide a base controller they both shared?

Mixins

To enable that, we have mixins. Mixins allow you to specify functions which are inherited by objects - in this case, our controller objects. This means, using mixins we can add new functions to a controller without needing to edit the controller itself.

A mixin is defined like so:

ips.controller.mixin('addAnotherMethod', 'core.global.core.example', true, function () { this.anotherMethod = function () { alert('Inside anotherMethod'); }; });
The ips.controller.mixin method takes up to 4 parameters:

ips.controller.mixin( name, controller, automaticallyExtend, fnDefinition )
name: Name to identify this mixin
controller: The controller this mixin extends
automaticallyExtend: [optional, default false] Does this mixin automatically extend the controller (more on that below)
fnDetinition: The function definition applied to the controller

In this example, our mixin adds a method named anotherMethod to our core.global.core.example controller shown earlier.

Let's talk more about the automaticallyExtend parameter. Mixins can be applied to controllers in one of two ways - either automatically on a global basis, or manually on a case-by-case basis. Mixins are manually specified like so:

<button data-controller='core.global.core.example( addAnotherMethod )'>Click me</button>
This means the mixin is used on this element - but another element using core.global.core.example wouldn't get it. This is useful when you're building your own apps or addons; you can write simple controllers that implement base functionality, then extend them with functionality for specific cases by specifying the mixin name in your HTML. We use this ourselves - for example, we have a base table controller that handles sorting, filtering and so forth. We then have a mixin for AdminCP tables, and a mixin for front-end tables, which add functionality specific to those areas, reducing code duplication.

If you're extending an IPS controller in an IPS app, though, modifying the HTML isn't typically an option. Instead, you can specify the mixin as global, and it will be applied to all elements where that controller is used. This means you can write your own mixins that work with our default controllers without having to touch our controller code (and that's a good thing).

Advice

So that shows how to add new methods to a controller. But what if you want to work with the methods that already exist in the controller? In the above example you'd only be able to overwrite an existing method - certainly not ideal, because 1) you would break any other mixins using the default method, 2) if we made an update to a method in a later release, your mixin would break it.

To facilitate working with existing controller methods, we're using a model called advice. This adds three special methods to a mixin: before, after and around. These let you 'hook into' existing methods and provide additional code for them. Let's rewrite our example mixin from above to take advantage of it:

ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.before('showAlert', function () { this.scope.css({ background: 'red' }); }; });
Here, I'm using the before method. I'm hooking into showAlert method (from the controller), and changing the background color of the scope element. So what happens when the link is clicked? First the background changes to red, and then an alert box is shown. We've added the background changing functionality without needing to edit the controller at all. Here's two other ways of doing the same thing, using the other two special methods:

ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.after('showAlert', function () { this.scope.css({ background: 'red' }); }; this.around('showAlert', function (origFn) { this.scope.css({ background: 'red' }); origFn(); }; });
The after method is fairly self-evident. With the around method, the original function is passed in as an argument, allowing you to determine when it is executed by your mixin.

All three of these methods will stack, so multiple mixins can hook into the same method, and they'll be executed in order, each receiving the previous.

Conclusion

I hope this introduction to mixins proves useful to developers; it shows how our core app controllers can be extended in a non-destructive way, but also how your own apps can use the mixin functionality to create an inheritance model to make your life easier.

Javascript in IPS4 makes extensive use of custom events, so the preferred way of adding new functionality is to listen for appropriate events and act on them - but the mixin support described above provides a mechanism by which you can adapt existing event handlers.