Elementor Container Spacing Issues on Older Browsers (Safari 14 & Under)

Using modern CSS and JavaScript can provide many benefits for websites, including improved design, performance and functionality. However, a small percentage of visitors, approximately ~3%, may not be able to experience the website as intended due to their browser's inability to support these technologies.

For instance, the limiting factors in the context of Elementor are CSS Variables, and ES6. The browser support is about 97% for CSS variables, and 96.7% for ES6. Whenever we choose Elementor for a project, we essentially accept that ~3% of the visitors won't be able to use the website as intended.

Generally speaking, it's a good tradeoff. The only way we could reasonably increase support further would be to use very outdated technologies, and it's just not worth it. The time and expenses saved, the improved look and performance of the site, make it worth it to give up on ~3% of visitors.

The Flexbox Gap

All of this was true until Elementor introduced the Flex Containers, and relied on the 'gap' property to space the items apart. The browser support for flexbox gap is much lower, at 93%. It is important to note that the 'gap' CSS property has different (and lower) browser support, in the context of Flexbox (~93%) than Grid (~96%).

For instance, on MacOS, Safari V14.0 and under don't support it. On iOS, it's Safari <14.5. These are very recent browser versions, indeed the recently released (end of 2020) M1 Macs all shipped with Safari 14.0!

All of this means that, for little good reason, you are displaying a partially broken website to an additional 4% of visitors.

Should you care?

Now, you might not care much.. after all, 4% isn't that many visitors. If you should care really depends on several factors, such as:

• How much traffic the website has to start with
• How much income is it generating
• How much you are getting paid to create that website

For instance, a 300 visitors/ month brochureware site can probably afford to show a broken layout to 4% of its visitors.

A 250k/month eCommerce site however, is likely not ready to give up on 4% of visitors (up to 10k income per month!) by showing landing pages that are broken, and that would drastically reduce conversion rate.

Previewing the problem

To preview the problem, even if you don't have access to a browser that does not support flexbox gap, you can simply add this CSS to your site (temporarily) or staging site.

<script> 
/* Please login to get the code 
 * The code will be for the Elementor Container Spacing Issues on Older Browsers (Safari 14 & Under) tutorial 
 * Found at this URL https://element.how/elementor-container-spacing-issues/ 
 */ 
</script>

That will reset all gap to 0px, replicated precisely what happens on browser not supporting it. This will allow you to see what your site looks like for visitors from browsers not supporting flexbox gap.

You will notice that it's not like everything is completely broken... but all the spacing between the elements will be gone. On a single product page, it won't help conversion rate! On a web agency website, it will essentially be a deal breaker for all leads but the most clueless about design.

The obvious solution

There is an obvious solution to this problem: provide some fallback CSS for browsers that don't support flex gap!

Well, it's not so simple, unfortunately. It turns out there is no simple way to provide a CSS fallback code, as the 'gap' property acts in a rather complex fashion. It adds gap in-between the items, but not around them. If the items wrap (for instance, on mobile, flex items that were in a row often become stacked in a column), then the gap spacing is added vertically, and not horizontally.

That's kind of why it came to be that we needed this new 'gap' property to start with: there wasn't any property or group of property that could efficiently replicate the behaviour.

While it's not impossible to add fallback CSS to replace the gap property in the context of CSS Flexbox, it is impossible to have it be dynamic and automatic.  Without JavaScript, that is...

The other obvious solution

Clearly you must have thought of it already: don't use the 'gap' setting! That does work. If you always set it to '0' (by default it is 20px), and space the items apart using their margin and padding settings, you don't have to worry about it.

However, it's a poor solution... first, if you found this article to start with, it's likely that you already have a complete website built, and just became aware now of the issue.

Also, the gap property is genuinely useful... and should have proper browser support in another ~2-3 years or so. So avoiding it isn't a great option.

The actual solution

The only way to solve the problem in the end is to write a relatively complex algorithm that will consider all the necessary factors to provide fallback spacing using CSS margins.

• It needs to consider the value of the gap property we are replacing
• It needs to consider the margins that were already in place
• It needs to consider wrapping, when elements that are in a row wrap in a new line, and add appropriate top margin to replicate the gap
• It needs to ignore all elements that have margin:auto; , so as not to break the flex behaviour of pushing the elements away with the available free space left
• It needs to ignore flex children that are position:absolute;, position:fixed; and display:none
• It needs to consider viewport resizing
• It needs to consider popup and tabs content
• Ideally it would work in both LTR and RTL text directions

So I went ahead, pulled up my sleeve and got to work!

The code I provide below considers all of the above scenarios. It should make your previously broken layout (on devices not supporting flexbox gap) go back to it's original state.

It does have a few limitations:

• Newly AJAX loaded content won't be subject to the fallback fix, at least not without additional custom coding from your part (you will just need to run the function after loading new content).
• Ditto for any content that goes from display:none; to display:flex;. Content that was inside a display:none; container won't automatically be processed with the fallback code, you will need to run the function.
• There is almost certainly bugs where the code won't work as intended, in very unique scenarios that I could not predict or account for. This should be well under 1% of cases though.
• I purposely didn't add support for vertical wrapping (flex-direction:column; along with flex-wrap:wrap; , and a set height on the container) as it's nearly never used in production.

The great thing is, despite these limitations, the fallback code will still help as it should in the supported scenarios. In other words, the code will always improve your site layout. It's just that sometimes, it won't fix everything.

How to implement the fallback solution

This is a bit more intricate than my other tutorials to implement, as we have to consider performance. We don't want 100% of users loading a piece of code that's only useful for ~4% of them.

Unfortunately, it's impossible to achieve this completely here. We have to have at least some JS that will check if the browser supports 'gap' in the context of flexbox.

So we have a very small JavaScript file that will load for everyone, that file will check if flexbox gap is supported, and if not, it will dynamically load the actual fallback code.

Here is the size of the file loading for everyone. Well under 1kb after gzip compression. So you don't have to worry about any performance impacts from having this fallback in place.

The codes

Here are the minified codes. Right click > download file for both of them, then upload them (via FTP or file manager) to your /wp-content/uploads/ folder.

https://templates.element.how/wp-content/uploads/fgcheck.min.js

https://templates.element.how/wp-content/uploads/fgfallback.min.js

After you have them in place in the uploads folder, we need to enqueue the fgcheck.min.js file.

<script> 
/* Please login to get the code 
 * The code will be for the Elementor Container Spacing Issues on Older Browsers (Safari 14 & Under) tutorial 
 * Found at this URL https://element.how/elementor-container-spacing-issues/ 
 */ 
</script>

Add this code in your child theme functions.php file, or in a PHP Code Snippet (avoid Elementor custom code feature).

In case you are curious and want to check the readable (unminified) version of the codes, here they are:

https://templates.element.how/wp-content/uploads/fgcheck.js

https://templates.element.how/wp-content/uploads/flex-gap-fallback.js

Making the most of the fallback

Just setting up the files above will have everything working fine in 90%+ of cases, without any further work from your part.

Still though, I coded in a few options to make the code as flexible and useful as possible.

Testing the results

To test the results even if you don't have access to a browser that does not support flexbox gap, I added a JavaScript property named _testFB.

You will need this code snippet in place:

<script> 
/* Please login to get the code 
 * The code will be for the Elementor Container Spacing Issues on Older Browsers (Safari 14 & Under) tutorial 
 * Found at this URL https://element.how/elementor-container-spacing-issues/ 
 */ 
</script>

As it's temporary, you can simply add it to your header, in an HTML element.

You will recognise the CSS we used earlier to preview the problem.

Here we are using it again to "cause" the problem, and then we are setting the _testFB property to true so that the fgfallback.min.js will be loaded and executed.

This will allow you to navigate through your site and see the fix in action. It will also allow you to see where a bit of customization might be needed, using the following options.

window._fallbackFlexGap()

First, if you have custom JS functions that changes the visibility of some elements, you will want to run the function again after an element is made visible.

I made the fallback function globally available at window._fallbackFlexGap() .

So you can simply add it to your custom JS, in your click function or such.

You will want to add this:

<script> 
/* Please login to get the code 
 * The code will be for the Elementor Container Spacing Issues on Older Browsers (Safari 14 & Under) tutorial 
 * Found at this URL https://element.how/elementor-container-spacing-issues/ 
 */ 
</script>

Example, if you had this code:

element.addEventListener('click',function(){
element2.style.display = 'flex';
});

You can add the fallback flex gap function:

element.addEventListener('click',function(){
element2.style.display = 'flex';
if (window._fallbackFlexGap !== undefined) window._fallbackFlexGap();
});

The recalculateOnClick setting

Similar to what we just saw, this is also used to rerun the function after clicking some element. This option however will require you to edit the fgfallback.min.js file directly, before uploading it.

Near the start of the file, you will find:

recalculateOnClick: '.elementor-tab-title', /* comma separated list of selectors that on click, should rerun the function */

You can edit that list of selector to match any elements that on click, you would like the fallback function to rerun.

The "exclude-from-fallback" class name

Another option built into the fallback code is the "exclude-from-fallback" class name.

You can give it to any flex container, or any flex children, and they will be ignored by the fallback code. In the rare cases where the code might be causing trouble instead of fixing it, just give this class name to the containers in question.

Why isn't this built in Elementor

That's a good question! I reached out to Elementor to give them this solution, free of charge! That way it's advancing the overall goal of Elementor: making web design as easy and seamless as possible. Nobody wants to have to think about these things, so having the fallback code be in place by default and the user not even have to think about it is really ideal.

Here is the official reply from Elementor:

Thank you for your feedback, we reviewed this again internally, and will not be implementing a fix regarding the matter, as Safari 14 and Safari iOS 14.5 are still used by a very small portion of visitors.

Although implementing your fix for the Element Gap can help this edge case of a site that has visitors using those old browsers, it will, at the same time, impact performance for that site and also for all our Elementor users who don't need it, this is not considered the best practice for all websites.

Here is my answer to their reply:

The effects on performance are indeed to be considered carefully. I went through extra lengths to minimize them, with the file being loaded for all visitors (regardless if they support gap or not) being well under 1kb.

Total performance impact: 1 extra resource, 0.2kb gzipped JS file.

If it was to be integrated with Elementor directly, the 'check gap support' JS would become part of an already existing and delivered JS file, and it could be minimized further, for a total performance impact of:

0 extra resource loaded, and ~0.1kb** gzipped added to the existing JS file.

This is really minimal, mostly considering everything Elementor loads already.

In exchange, you add support for 4% of visitors world wide. All the data I used in the article comes from caniuse.com, which is global user data. In certain area of the world, and for different kind of websites, it will vary up and down, but overall, across the 10M Elementor websites, it should be pretty close to what caniuse.com represents: 4% of visitors.

In actual visitor count across so many websites, it's millions of visitors per month that instead of seeing the broken layout, would have the fixed version.

So in light of this I ask you and the dev team to please reconsider carefully this decision.

Thank you!

[**in the end after minifying as much as possible, I got the file down to 248 bytes.]

I haven't heard back yet from that reply, I don't think they will change their decision. After all they do raise a good point. Loading extra stuff should always be considered carefully. I just wish they had that mindset since the start of Elementor, and that we would not already be loading 100kb+ of JS by default [uncompressed]...

In any case, if you think the trade off is worth it (0.2kb extra for 4% greater browser support), you can share your concerns with them about this by reaching out to their support or through their Github. Maybe if enough people care, they will integrate such a fallback solution.

With Elementor running on 10M websites, increasing support for 4% of visitors would be massive and users would be very thankful.

Conclusion

Credits to ishadeed for the function to check if flexbox gap is available.

I hope you have enjoyed this tutorial. A lot of work went into it. Let me know if you found it helpful and if you learned something!

Cheers!