Open kevkevinpal opened 6 months ago
@kevkevinpal @ecurrencyhodler @elraphty yeah I'm seeing a lot of these z-index values while creating this new input component. Which makes the ui bit wonky, if you adjust anything related to positioning, I'm thinking about re-ordering the structure, or using alternatives such as visibility or opacity, what are your thoughts?
@Vayras I updated the issue some more context. We are going to remove z-indexes when applicable but keep them in modals. Raph is going to go through these and create bounties.
@ecurrencyhodler That's great I hope this brings some sort of uniformity and make the ui more cohesive 🚀
Here are my notes from chatting with Rasul.
1. On researching modals to portals Modals can be done through react portals.
Example:
<div id="app" />
<div id="modals-portal" />
In this scenario, modals are always over the main app. This will help with structuring our website well.
First we should know if we are using modals through portals. If not, we need to research how difficult that is.
2. On moving modals to portals This should be done before step 3. Downgrading z-indexes will not fix anything instantly but modals may fix a lot and remove a lot.
3. On downgrading z-indexes We should go through all the files and minimize z-indexes. For example if two elements have a large difference (1 or 100), we should make it smaller and logical such as: 1->2.
We will eventually replace and restructure z-indexes when appropriate but starting with downgrading will help prevent breaking the site and remain backwards compatible.
4. On restructuring z-indexes There are many factors to consider when using z-indexes well.
For example, z-indexes aren't applied all the time. It needs other styles and positioning to be applied in order to make it work. May have 1 z-index in one place but not in another because they have their own layering logic.
Also reusable components have the same initial z-index but can be overwritten in specific landing pages when needed.
Lastly, there are places where it should be avoided. For examples, #225. We are using z-indexes to handle drop down which isn't best practices. Instead dropdowns should have their own layer that stays above other content. This can be handled through markdown.
Another plan we discussed in standup today:
Okay here is the final discussion with kevin and rasul.
Portals is native to react and therefore isn't adding an extra dependency. The difference between using our custom modals vs. portals is that we are handling z-indexes ourselves. Using portals will help us avoid doing that.
In light of this, we have decided to use portals.
Rasul will also take a look over the weekend at our project and dig into the best way to handle z-indexes. He may also quickly address some issues. Then he will provide a specific plan for us to turn into a bounty to wrap up this issue.
Context
Right now we're using z-index in a lot of places.
Z-index takes a component and moves it forward/backward a certain amount. For example, say you have a button overlapping another component, if you give a button a higher z-index it’ll cover the other one.
More practically, issue #225 is a great example of the types of unwanted visual effects it can introduce.
In #225, the z-index on the tag (titles of boxes in the profile that appears on top of the drop down) is higher than the drop down. The hunter proposed a solution which was to simply increase the z-index on the dropdown menu. As you can see, manually setting z-indexes aren't a great approach to layering components especially if we introduce another component.
Therefore we should try and minimize the amount of
z-index
's we use because they can end up covering other components and are inefficient to manage. The only caveat being that the times when z-indexes are useful are inside of modals.Below is a search command to look for z-index however the ones related to modals have been removed.