Since PRO 3, for certain layouts, elements with x-anchor-content class overlap others due to the addition of z-index:2 (only Icon stack tested)

Hi,

After updating to PRO version 3 I started to get overlapping issues between elements, like the following one:


The problem comes from the addition of the z-index:2 CSS rule to the x-anchor-content class that was made in PRO Version 3, in /pro/framework/dist/css/site/stacks/icon.css:

.x-anchor-content {
   overflow: hidden;
   display: flex;
   flex: 1 0 auto;
   position: relative;
   z-index: 2;
   border-radius: inherit;
   transform: translate3d(0, 0, 0)
}

In other versions prior to PRO version 3 the z-index:2 rule was not present for the x-anchor-content class.

Please, take into account that:

  • I have never experienced this issue until PRO version 3, at least not for the past 2 years.

  • The HTML code of the element that overlaps (remains above) –in the aforementioned example, the phone number– goes before the code of the overlapped element –in our example, the site search field–. Because of that if z-index was unset for the x-anchor-content class –as it used to be before PRO version 3– we would not be getting the overlapping issue:

Thanks!

Hi Abarka,

That is correct. Please kindly check our release notes here:

Kindly read the Why is custom CSS on my button no longer working? section of the FAQ.

Thank you.

Hi @christopher.amirian,

I have read your release notes. You specifically pointed me to the “Why is custom CSS on my button no longer working?” section of the FAQ but here is the thing, I haven’t got any custom CSS in the button that is experiencing the issue. This means that for certain layouts –even if the user does not employ custom CSS in the button– the overlapping issue occurs.

Thank you.

Hey Abarka,

I’ve tested the latest version of Pro and the only way I could replicate the overlapping button is if your Button is in the 2nd bar of the Top Header and the Search Dropdown is in the 1st bar or in the Right Header.

In those cases, the z-index of the 2nd bar in the Top Header should be lower than the z-index of the Bar containing the Search Dropdown.

If that is not your setup, please give us the URL of the page having this issue so we could see your setup? And, we kindly ask that you do this each time you ask for support so we could check the setup immediately and not have to guess which saves us time which is good for all customers because our responses will be faster and back and forth conversion will be avoided if not lessened.

Thanks.

Hey @christian_y,

Thank you for your efforts trying to replicate the issue. I apologise for not having shared the URL. I thought that it was going to be easy to replicate the issue for you without it, obviously I was wrong.

I must clarify that when I created this support thread I had already come up with the custom CSS I needed to solve the issue –for my specific case– as it was very simple, so I do not need you to provide me with a solution.

The purpose of opening this thread was to:

  • Raise awareness about the fact that the addition of z-index:2 to the x-anchor-content class might cause issues to users in certain case scenarios.

  • Get an explanation about why the development team decided to make this change. This way, understanding the reason behind such modification I could make better decisions when solving the issues derived from it. For example, the most straightforward solution I found –to solve the issue I experienced– was to add custom CSS to my button to revert form z-index:2 to z-index:auto, but perhaps I am doing it wrong because there may be a good reason for keeping z-index:2 so I might probably be better off using a different solution.

In my case the issue was not related to any custom CSS on my button but to custom CSS on the Search Dropdown that follows the button –within the same container, thus within the same bar–:

The custom CSS present on the Search Dropdown (x-mod-container class) that was clashing with the new button’s z-index:2 was transform: skew(45deg) translatex(19px);. The overlap happens due to the fact that the property transform creates a new “stacking context”.

Here you have the URL (I created a header for testing purposes):

Thanks.

Thanks for your explanation, Abarka. It is not easy to replicate this since this is not a common use case. And, because it’s the custom CSS that is causing the issue, it is your web developer that is responsible to provide the fix. All custom CSS should be checked when updates are applied because theme and plugin developers could change the code base without prior notice and providing the reasons as it is not feasible to explain all the code changes. But generally, the reasons are for improvement or fix for an issue.

Thanks.

OK, fair enough.

Thanks!

You are most welcome!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.