In the past - during development and integration of new features there were a lot of reported issues/bugs due to the current way of usage of z-indexes values. The biggest example, where z-indexes were a big problem, is probably NavBar or CookiesConsent components.(MobileAd, )
If possible, add some statistics about the reported problems(z-indexes).(NavBar, CookiesConsent, MobileAd)
Analysis of the values used on FE
The analysis of the current used values for z-index attribute shows that there are 254 different values used in JS or STYLUS files. Only 54 of them are unique, so the actual scale doesn't seems wrong, but deeper insight into values is needed.
Major part of the values is between value-1 and 10 and it is reasonable. These values are often used just for developing simple UI components/layouts when the dev needs to reorder some visual layers.
the biggest used value is 100001 and there are a lot more of them.
Layering the frontend
The whole frontend(search, booking, mmb and orbit/nitro) can be simply divided into many layers(from bottom to the top) that will have unique z-indexes on proper based scale.
Main application
Search form has value 101 and 25 when showed results
scrollToTop button(fixed, 100)
Booking(probably nothing special)
MMB
ChatIcon(right bottom corner) value 6000 fixed
ScheduleChanges(below SmartFAQ with NavBar)
NavBar(current value 824 with position relative)
Popup for Starred(50, absolute)
SideNav(current value 825 with position fixed)
CookiesConsent(fixed 600, mobile 610 relative)
SmartFAQ(6050, fixed)
Modals
Popovers
Tooltips
Proposed solution
Therefore there is need to be proposed some framework how to work with z-indexes across multiple products(Orbit and Nitro) and the main repository too.
The definition of a problem
Analysis of the values used on FE
Layering the frontend
Proposed solution
Full table of used z-indexes