Linux-Is-Best

4.5 introduces some changes to CSS, so I wanted to provide an overview of those and how they might affect you.
 
IE11
Firstly, we've completely dropped support for IE11. This means you'll start to see newer CSS methods being used that IE11 does not support. 
 
Atomic classnames
One thing you'll notice as you read on is we're moving towards using atomic classnames for utility styles. What does that mean? Basically, each classname is just a convenience helper for applying one particular style. You build how an element looks and behaves by applying multiple classnames. 
While this is slightly more verbose in the HTML, it's also much clearer and avoids having to create mutant selectors that exclude certain elements. If you see an element with ipsBorder_top, it's obvious what it does. Don't want a top border? Just remove that class.
Another benefit is that it allows more precise control over how styles are applied at different device sizes, because individual styles can be modified. Want a top border on desktop, but not phones? ipsBorder_top sm:ipsBorder:none will do the job - no crazy selectors or additional media queries necessary.
 
Class prefixes/modifiers
Wait, what's that sm: bit in the atomic classname example above? That's a new naming convention you'll see which controls at which breakpoints the style is applied.
Unprefixed (e.g. ipsBorder_top). Applies to all devices, desktop and smaller. md: (e.g. md:ipsBorder_top). Applies to tablets and smaller. sm: (e.g. sm:ipsBorder_top). Applies to phones only. sm and md prefixes take priority over the desktop classname. This means you provide the desktop classname but can override it for tablets and/or phones by also adding an md: or sm: classname. For example, ipsPadding_top:double sm:ipsPadding_top:half applies double top padding on desktop, but only half top padding on phones.
You'll also see modifiers on some classes (as in the example above), for example ipsPadding:half. ipsPadding is saying 'apply padding to all sides', and the ':half' modifier makes it a smaller amount.
 
BEM classnames for modules
While we're using atomic classes for global utility styles, we're moving towards BEM for module-specific classes. BEM is simply a naming convention, so it doesn't have too much impact on you - you'll just see a new structure for new classnames that should be easier to understand. 
 
Note: We haven't rewritten our CSS framework with the atomic classname, class prefix/modifier or BEM approaches. Don't worry - 90% of the classes you're used to will be the same. I just wanted to point out that going forward, new classes will follow these paradigms.
 
CSS Variables & calc
We're now making use of CSS variables (also known as CSS custom properties). Check out this MDN article if you aren't familiar with them. This enables us to define some values in one place but use them throughout the product - and it allows you to change the value in one place if you wish to do so for your theme. Most of our CSS variables are defined at the top of global.css in the CSS framework, but you'll also see some other local variables defined in other places. Variables are simply used by wrapping the name in the var() function, e.g. var(--positive-light). 
You'll see some variables named --sp-1 and so on. This is our new 4px spacing scale. In 4.5 and going forward, when we style elements we'll generally be using one of these values for widths, heights, borders, spacing etc. to keep everything consistent. You should do the same for elements you create.
We're also making use of calc(). This is another CSS function that allows math operations to be done. Instead of having to hardcode numbers for positions, sizes etc., we can now use calc() to do it for us based on some other values (often CSS variables).
CSS Variables for theme settings
We are deprecating the usage of the {theme} and {hextorgb} tags for color-type theme setting keys (but not for non-color settings or when you need to pass a specific hex code in).
Instead, color-type theme settings will automatically have a CSS variable created for them, named --theme-setting_key, where setting_key is the key of the setting as defined in the AdminCP. The variable will be a triplet representing the color, for example 255, 255, 255. Therefore, this value can be used with both the rgb and rgba CSS color functions.
Here's an example. If in the past you'd wanted to use the area_background theme setting in your CSS, you'd do background: {theme="area_background"}. Or if you want some opacity, you'd do background: {hextorgb="area_background" opacity="0.2"}.
In 4.5, the correct way of using these will be: background: rgb( var(--theme-area_background) ) and background: rgba( var(--theme-area_background), 0.2 ) respectively.
We're doing this now because it will open up some exciting functionality in future. To be clear, any existing usage of {theme} and {hextorgb} will continue to work fine in 4.5, but we encourage you to move over to the CSS variable approach.
 
Hardcoded hex values
In 4.5 we have largely removed all hardcoded hex colors from our CSS files, and adjusted styles to use theme setting values instead. This will make it much easier for admins to fully colorize their theme without hardcoded colors messing things up. I encourage you to update your app's CSS to follow this approach.
 
Font sizes
We've moved font sizes to a fixed scale. These have been implemented as theme settings so they are customizable. However, rather than use the theme setting value directly, you should make use of the new {fontsize} plugin. This plugin ensures the global scale is applied to any values passed in, allowing 'large print' versions of themes to be easily created. You should use the {fontsize} plugin for font sizes both when you use one of the theme settings and when you use specific pixel values (e.g. {fontsize="72"} - for 72px text)
When used with the {fontsize} plugin, the type scale keys are:
x_small (12px) small (13px) medium (14px) base (16px) large (18px) x_large (20px) 2x_large (24px) 3x_large (30px) 4x_large (36px)  
Flexbox
While we've used flexbox in some places in previous versions, 4.5 makes much wider use of it and also introduces a new family of classes. If you aren't familiar with flexbox, I highly recommend this CSSTricks article for a primer on it. Essentially, instead of positioning elements using floats/clears/etc., flexbox treats the container as a flexible box with properties for controlling how elements inside of it as laid out.
4.5 has a number of new classes that are essentially just convenience for the usual CSS rules.
ipsFlex (sets element to display: flex) ipsFlex-ai:start, ipsFlex-ai:center, ipsFlex-ai:end, ipsFlex-ai:stretch (ai - values for align-items property) ipsFlex-as:start, ipsFlex-as:center, ipsFlex-as:end, ipsFlex-as:stretch (as - values for align-self property) ipsFlex-jc:start, ipsFlex-jc:center, ipsFlex-jc:end, ipsFlex-jc:around, ipsFlex-jc:between (jc - values for justify-content property) ipsFlex-fd:column, ipsFlex-fd:row, ipsFlex-fd:column-reverse, ipsFlex-fd:row-reverse (fd - values for flex-direction property) ipsFlex-fw:wrap, ipsFlex-fw:nowrap, ipsFlex-fw:wrap-reverse (fw - values for flex-wrap property) ipsFlex-flex:10 - sets flex-grow: 1 and flex-shrink: 0 ipsFlex-flex:11 - sets flex-grow: 1 and flex-shrink: 1 ipsFlex-flex:01 - sets flex-grow: 0 and flex-shrink: 1 ipsFlex-flex:00 - sets flex-grow: 0 and flex-shrink: 0  
All of these classes have md and sm prefixed versions too, and this opens up the possibility of having different layouts on different device sizes in a way that's much easier than the hoops you'd have to jump through before. For example, to create some elements that show as a row on desktop but collapse to a column on mobile, you'd just apply ipsFlex ipsFlex-fd:row sm:ipsFlex-fd:column. The sm:ipsFlex-fd:column class overrules the ipsFlex-fd:row class on mobile, adjusting the layout. (Note: flex-direction: row is the CSS default direction anyway, so you can actually leave out ipsFlex-fd:row - it's implicit. I included it in the example for clarity.)
 
Padding/margin
We've added new spacing classes for padding and margin, to allow for atomic classnames, device prefixes and modifiers.
ipsPad, ipsPad_double, ipsPad_half, and all of the ipsSpacer_* classes are now deprecated. You'll still see them in our templates and they'll still work in yours, but don't use them in any new work - you should use the updated classes below.
The padding classes are now named ipsPadding:
ipsPadding, ipsPadding:none, ipsPadding:half, ipsPadding:double - apply padding to all four sides ipsPadding_vertical, ipsPadding_vertical:none, ipsPadding_vertical:half, ipsPadding_vertical:double - apply padding to top and bottom ipsPadding_horizontal, ipsPadding_horizontal:none, ipsPadding_horizontal:half, ipsPadding_horizontal:double - apply padding to left and right ipsPadding_left, ipsPadding_left:none, ipsPadding_left:half, ipsPadding_left:double - apply padding to the left side (RTL aware) ipsPadding_right, ipsPadding_right:none, ipsPadding_right:half, ipsPadding_right:double - apply padding to the right side (RTL aware) ipsPadding_top, ipsPadding_top:none, ipsPadding_top:half, ipsPadding_top:double - apply padding to the top side ipsPadding_bottom, ipsPadding_bottom:none, ipsPadding_bottom:half, ipsPadding_bottom:double - apply padding to the bottom side These classes have md and sm prefixed versions too, allowing you to apply different padding depending on the device size.
One side note here: with the old padding classes, padding was simply halved on phones with no opt-out. That's not the case with the new family - if you want half-padding on mobile on an element, you should apply sm:ipsPadding:half in addition to the normal ipsPadding class, for example. This gives you much more control than you previously had.
Margins follow basically an identical pattern to padding, with the same variation of classes, except the name is ipsMargin.
 
Gaps
Another new family of classes is ipsGap. These classes are used when you want spacing between elements. In the past, you'd have to use :last-child or :first-child to exclude an element, or loop over the elements in the template to leave off a class. If elements wrapped to a new line, putting spacing between the lines was tricky too.
ipsGap solves this by applying even spacing between elements, then applying a negative margin on the whole container to bring it back to the starting position.
The classname is followed by a modifier, which is a number from our spacing scale, e.g. 1 is 4px spacing, 2 is 8px spacing and so on.
ipsGap:1 (1-5 available) - applies both horizontal and vertical spacing around each element in the container ipsGap_row:1 (1-5 available, as well as 0 to remove) - applies vertical spacing on each element in the container Notice ipsGap_row also supports the :0 modifier. This allows you to have horizontal-only spacing - simply apply ipsGap:1 ipsGap_row:0.
Be aware that using both ipsMargin (or custom styles that apply a margin) and ipsGap on the same element can cause issues. You may want add a wrapper element to handle your margin in this situation.
 
Borders
We've also added a class family to add light grey 1px borders to elements - used commonly as dividers between some parts of the page.
ipsBorder - apply border to all sides ipsBorder:none - remove border from all sides ipsBorder_vertical - apply border to top and bottom ipsBorder_horizontal - apply border to left and right ipsBorder_top, ipsBorder_bottom, ipsBorder_left, ipsBorder_right - apply border to a particular side These classes have md and sm prefixed versions too, to control borders shown on each device size. This is particularly useful if you apply a border to a flex child which is in a row on desktop but a column on desktop, for example - you will be able to easily control which side the border appears on once collapsed.
 
"Pull" class
To better display content areas on mobile, a class named ipsResponsive_pull has been added which 'pulls' a box on the left and right sides on small devices. It's intended to be used on boxes (normally with the ipsBox class) that you want to take up the whole screen width on mobile, allowing better usage of the available screen space.
 
Template changes
We've worked to keep template changes as minimal as possible, but in an update the size of 4.5 there are still quite a number of changes. Whether these impact you will depend on if you've modified the template (for theme designers) or rely on a particular selector for theme hooks (for developers).
One area that has received fairly big changes is the post/comment templates. We have redesigned the headers and footers of these templates and moved some elements into a separate parent element on mobile devices.
As usual, full template changes will be available once we've released betas.

If a guide is out of date, just hit the report button and let us know. Someone will update it soon after we're aware. (Google and Facebook especially change their interfaces very often).

I like where your head is at! Yes, we will definitely be taking a look at the Help Guides and documentation, but not in tandem with the website revamp. We will need to sit down and focus solely on that project in the near future as it'll be a relatively big (but awesome) undertaking. This feedback is valuable though thank you! 

Hey Dave, I've recently set up Google Maps both in the ACP and separately (async load with init callback) in my evolving jobs app. I know you are making a bigger point here. which I agree with, but in the meantime if I can be of any help, drop me a line.

When doing your refresh can you also take a look at the help files?  Some are way out of date and most don't give clear examples on how to implement some of the options available.  Not everyone is a PHP coder, but many don't mind getting their hands dirty now and then to make some positive changes to their sites.
An example would be (and this is just an example as it comes to mind) - how to implement Google Maps.  The instructions are out of date and it was a minefield navigating how to set it up - I gave up at the finish.  Another would be how to use custom fields and how to best use them, including any CSS examples that are needed to dress those fields so they look the part. Plain English examples are needed.
I'm sure that a lot of people would appreciate being able to make changes without any horror stories occurring.  As the suite evolves so should the help files and if you are including community enhancements that involve third parties, who are also evolving, then the help files should reflect this.  I believe this is just as important as a site refresh and apologies for hijacking the topic, but a refresh should be more than just some site cosmetics 🙂
 

Yeah, 10 was overkill. I agree 3 or 4.

I'm to old to be able to do 10 humps, 3 maybe, 4 on a good day

So 4.6 will be releasing tomorrow (thursday) ? 

Known issues with v1.1.0 (see screenshot 1)
No icon on left hand side, guiding you to the application's settings No header on the application's settings Both will be fixed in a v1.1.1 release at some point (I'm not releasing an update just to resolve language string issues) but can be resolved manually now by creating the following language phrases manually:
menutab__neapps (see screenshot 3) menutab__neapps_icon (see screenshot 4) Screenshot 1:

 
Screenshot 2:

Screenshot 3:

Screenshot 4:

Update // September 14, 2021: WE MADE IT! 
After months of hard work behind-the-scenes, we launched our newly-refreshed website and community theme. We have a formal blog post about it on the way, but we wanted to share this soft launch with you first 🤫. Feel free to share your feedback in the comments; we're here for you and are chatting! 
 
Earlier // May 12, 2021:
 


Hey all, Happy Hump Day!
@Charles and I joined forces here in Las Vegas this week because we're planning something super exciting. 🤐😎 
After 4.6 rolls out, we're focusing on freshening up our homepage/subsequent pages and match that branding with this community. That may or may not be an understatement, but if there's anything to take away from this teaser it's that there some slick visual changes on the way!  
If you guys have any websites/homepages which are clean & minimal that inspire you, we'd love for you to drop some links in the comments. We already do have a firm idea/concept planned out, but your opinions matter to us! We'd like to hear from you. 

Hello @Matt
Thank you for following up with my requested inquiry (and feature request to change the editor in the future).  I understand we have two (2) years to consider this, plenty of time for the development team to explore their options. In fact, that is why I made the request now, as opposed to later. I understood changing an editor would be an in-depth process and not a decision that could be made hastily. So it made perfect sense to make my inquiry now, as opposed to making this inquiry moments before CKEditor becomes the end of life.
I am currently using CKEditor 5 in another development. I have not been amused anymore than I am with CKEditor 4.  Most notably, the issues I experience have to do with how CKEditor works with mobile designs and layouts.  As I previously said, ideally, you want your editor not to be the focus of your development. By that, I mean to say the editor should blend effortlessly in the background as something you do not notice (an afterthought). So many developments no longer use CKEditor because the editor itself often gets in the way. I cannot count how many times when I have heard or experienced why something was not functioning right because of the editor. Or why something could not be developed or extended because of the editor. The editor (CKEditor) is not the afterthought it should be. Even here on Invision, the editor and its limited functionality has proven problematic by the sheer request to work around it https://invisioncommunity.com/search/?q=editor&quick=1&type=forums_topic&nodes=499
I want the good folks within Invision to know that I and many here respect where you have been taking your development. I like all the many features you have incorporated, and I am excited to see where Invision may be going in the future.  But the editor (CKEditor) is indeed something of an annoyance. I currently have no doubt when Invision decided to use CKEditor; at the time, it was the best option available. Times change.
I do not expect Invision to change editors overnight. As previously pointed out, it is not easy to change editors or upgrade editors. I do not expect an editor change in the next release.  My request was for the far-off future, perhaps Invision Community 5.0 (whenever that happens). Again, we have a whole two (2) years before CKEditor reaches the end of life. Plenty of time for the Invision team to explore their options available.
I hope (and request) that Invision explores their options during that time and hopefully decides on a different editor in the future.
 

Hi Gazza!
Yes, this is enabled by our Progressive Web Application (PWA) improvements coming soon in 4.6
 

I can't see this anywhere after searching keywords as I thought it would've come up before.
So, just like Invisions Homepage when visiting it via mobile browser, it offers you the chance to add the Homepage to your mobile phone so it looks just like an app but essentially is just a shortcut/bookmark for your homepage.
I would expect this is to be a brilliant edition for most people as many people browsing on a phone, you wouldn't believe do not know how to create a shortcut to the homepage on their phone and the option that is presented at Invision, just like many other websites is very sleek and gives the member a choice. Certainly helps with the push notifications a lot as it shows the notifications on the homepage 'app' icon on your phone.
Or am I jumping the gun and this is coming inbuilt with 4.6?
Many thanks in advance

It’s better to reach out to them yourself: https://invisioncommunity.com/third-party/providers/

So IPS is used for literally EVERYTHING you can think of
Gamers, Companies, Gaming/Clan/Team Communities, and a lot more Use IPS
So seeing that there is A LOT of Gaming/Clan/Team Communities that use IPS, why not give us a chance to be able to sell our own Merch? 
By this i mean, using a integration feature using 3rd party Drop Ship/Fulfillment Companies 
Examples - Printful, Printify, CustomCat
They have a section where Places like Wordpress and other big sites can directly integrate their store with said Places above. 
 
This doesn't just have to be appreciated only by us Gaming Communities, anyone who wants to sell their own merch, but bypass all the leg work, this would be good for all, and also IPS advertising they have this Feature for Commerce integration, IMO, would attract even more business, and more conversions to IPS (all the legal/returns/laws, all fall on the hands of IPS cliente, and the actual Fulfillment Platform) IPS would only be responsible for the integration............ a clean seamless connect with Drop ship/ Fulfillment companies to sell your own Merch!
 
Looking forward to @Joel R to look at this, break it down, tell us the pros & cons of this...... (Not making a Joke...serious about wanting to see his reply...and others that are well into the skeleton of IPS, and IPS themselves) 

It took me a while to realize that the whole page was the demo and that you could change anything on the page.  Usually, when I see an editor demo, they confine it into a box somewhere on the page, not the whole page.  I am not complaining. I am only pointing out that fact, so others who visit your suggestion are not confused about where the demo is located.  😉

Yes.
I invite everyone to check out the suggested demo I linked in my OP post.  Please, do, test the page load times, responsiveness, and mobile usage of the editors.  For those of you who are more skilled and who are able, I also invite you to check out the underlined code.  Do compare and see for yourself (absolutely).
CKEditor 5 -- https://ckeditor.com/ckeditor-5/demo TinyMCE -- https://www.tiny.cloud/docs/demo Froala -- https://froala.com/wysiwyg-editor Quill -- https://quilljs.com Redactor -- https://imperavi.com/redactor These, of course, are only a small handful of possibilities.  There are many other alternative editors available, and if anyone would like to suggest something else, please do.
 

Hello @Matt
Thank you for following up with my requested inquiry (and feature request to change the editor in the future).  I understand we have two (2) years to consider this, plenty of time for the development team to explore their options. In fact, that is why I made the request now, as opposed to later. I understood changing an editor would be an in-depth process and not a decision that could be made hastily. So it made perfect sense to make my inquiry now, as opposed to making this inquiry moments before CKEditor becomes the end of life.
I am currently using CKEditor 5 in another development. I have not been amused anymore than I am with CKEditor 4.  Most notably, the issues I experience have to do with how CKEditor works with mobile designs and layouts.  As I previously said, ideally, you want your editor not to be the focus of your development. By that, I mean to say the editor should blend effortlessly in the background as something you do not notice (an afterthought). So many developments no longer use CKEditor because the editor itself often gets in the way. I cannot count how many times when I have heard or experienced why something was not functioning right because of the editor. Or why something could not be developed or extended because of the editor. The editor (CKEditor) is not the afterthought it should be. Even here on Invision, the editor and its limited functionality has proven problematic by the sheer request to work around it https://invisioncommunity.com/search/?q=editor&quick=1&type=forums_topic&nodes=499
I want the good folks within Invision to know that I and many here respect where you have been taking your development. I like all the many features you have incorporated, and I am excited to see where Invision may be going in the future.  But the editor (CKEditor) is indeed something of an annoyance. I currently have no doubt when Invision decided to use CKEditor; at the time, it was the best option available. Times change.
I do not expect Invision to change editors overnight. As previously pointed out, it is not easy to change editors or upgrade editors. I do not expect an editor change in the next release.  My request was for the far-off future, perhaps Invision Community 5.0 (whenever that happens). Again, we have a whole two (2) years before CKEditor reaches the end of life. Plenty of time for the Invision team to explore their options available.
I hope (and request) that Invision explores their options during that time and hopefully decides on a different editor in the future.
 

To clarify:
TinyMCE - since 2004 (17 years) Froala - The parent company (Idera, Inc.) since 2000 (21 years), the editor since 2013 (8 years) Quill - since 2013 (8 years) Redactor - since 2009 (12 years) Nothing I have suggested is a short-term 'fly-by-night' type of company. They are it for the long run. 😉 

Back in the day (long ago), nearly every project and development I know about used CKEditor. In its heyday (gold age), WYSIWYG editors were still a relatively new concept (I feel old. ), and CKEditor was considered top of the line. Times have changed.
Ideally, you want your editor not to be the focus of your development. By that, I mean to say the editor should blend effortlessly in the background as something you do not notice (an afterthought). So many developments no longer use CKEditor because the editor itself often gets in the way.  I cannot count the many times when I have heard or experienced why something was not functioning right because of the editor.  Or why something could not be developed or extended because of the editor. The editor (CKEditor) is not the afterthought it should be.  Even here on Invision, the editor and its limited functionality has proven problematic by the sheer request to work around it https://invisioncommunity.com/search/?q=editor&quick=1&type=forums_topic&nodes=499
Speaking personally, I love where Invision is going. I admire their creativity in where they are taking the development. I enjoy many of the features and am looking forward to the new features they have suggested they have planned. But I dislike the editor. It is my 'pet peeve' for Invision. I know of only two developments that still use CKEditor (the other is not a forum, and they use CKEditor 5). In both of them, I dislike the editor (v4 and 5). Why? Because in both of them, nearly all the issues I encounter, all the bugs I stumble upon, and all lack of functionality and adaptability surround CKEditor.  Besides Invision, only vBulletin, whose market share is shrinking and development has become stagnant, concerning forum software, still uses CKEditor.   
I do not expect Invision to change editors overnight. As SeNioR- pointed out, it is not easy to change editors, not even to CKEditor 5.  So regardless of the discission (whether we stay with CKEditor or change editors), we are still looking at a large transition. We have two (2) years to think this through and explore our options before CKEditor 4 reaches the end of life. Plenty of time to think this over.
You'll note I did not specify any particular editor (besides a few examples I gave). My request is not to promote any specific one, only that an exploratory investigation be conducted and that Invision considers their options.
 

CKEditor 4 is reaching the end of life (source). Instead of jumping onto the CKEditor 5 bandwagon, I propose Invision consider an alternative editor. There are many well-established modern editors such as, for example, TinyMCE, Froala, Quill, and Redactor, to name a few. Any of these would make satisfactory alternatives.
 
CKEditor may be 'old school,' but it has become bloated, larger in file size and load time.  Most of the issues it encounters often have to do with responsive layouts on a mobile device and excessive load time. As mobile continues to dominate the landscape, I feel it may be prudent to focus on an editor development that has kept up successfully with the times with the least issues.
 
Changing the editor should not be expected in the next release. But a roadmap should be considered for a future transition.  Thank you for your time and consideration. 😀

Gutenberg 

Yes.
I invite everyone to check out the suggested demo I linked in my OP post.  Please, do, test the page load times, responsiveness, and mobile usage of the editors.  For those of you who are more skilled and who are able, I also invite you to check out the underlined code.  Do compare and see for yourself (absolutely).
CKEditor 5 -- https://ckeditor.com/ckeditor-5/demo TinyMCE -- https://www.tiny.cloud/docs/demo Froala -- https://froala.com/wysiwyg-editor Quill -- https://quilljs.com Redactor -- https://imperavi.com/redactor These, of course, are only a small handful of possibilities.  There are many other alternative editors available, and if anyone would like to suggest something else, please do.
 

Hello @Matt
Thank you for following up with my requested inquiry (and feature request to change the editor in the future).  I understand we have two (2) years to consider this, plenty of time for the development team to explore their options. In fact, that is why I made the request now, as opposed to later. I understood changing an editor would be an in-depth process and not a decision that could be made hastily. So it made perfect sense to make my inquiry now, as opposed to making this inquiry moments before CKEditor becomes the end of life.
I am currently using CKEditor 5 in another development. I have not been amused anymore than I am with CKEditor 4.  Most notably, the issues I experience have to do with how CKEditor works with mobile designs and layouts.  As I previously said, ideally, you want your editor not to be the focus of your development. By that, I mean to say the editor should blend effortlessly in the background as something you do not notice (an afterthought). So many developments no longer use CKEditor because the editor itself often gets in the way. I cannot count how many times when I have heard or experienced why something was not functioning right because of the editor. Or why something could not be developed or extended because of the editor. The editor (CKEditor) is not the afterthought it should be. Even here on Invision, the editor and its limited functionality has proven problematic by the sheer request to work around it https://invisioncommunity.com/search/?q=editor&quick=1&type=forums_topic&nodes=499
I want the good folks within Invision to know that I and many here respect where you have been taking your development. I like all the many features you have incorporated, and I am excited to see where Invision may be going in the future.  But the editor (CKEditor) is indeed something of an annoyance. I currently have no doubt when Invision decided to use CKEditor; at the time, it was the best option available. Times change.
I do not expect Invision to change editors overnight. As previously pointed out, it is not easy to change editors or upgrade editors. I do not expect an editor change in the next release.  My request was for the far-off future, perhaps Invision Community 5.0 (whenever that happens). Again, we have a whole two (2) years before CKEditor reaches the end of life. Plenty of time for the Invision team to explore their options available.
I hope (and request) that Invision explores their options during that time and hopefully decides on a different editor in the future.
 

I honestly don't give a sh*t about what editor is used as long the user experience is satisfactory, and I think it is at the moment.
Of course if migrating to V5 requires as much work as migrating to another editor IPS should definitely benchmark all options and I have no reason to believe they won't. But it is really their problem in the end.