origin of the problem
This is a normal page itself and there is no problem. When some users have a low resolution, then the problem comes out.
This page becomes like this
It's okay to look at it this way, right? If I open a box , the result will be like this:
The bottom will be obscured so the user needs a scroll bar to pull the content down to reveal it. After adding scroll bars. .
It seems that the problem has been solved, but a new problem has come again. Before the scroll bar was added, the menu popped up like this
After adding the scroll bar, the page pops up and there is no response . I found the reason and looked at the structure of the web page. I drew a picture to represent it.
Their relationship is the parent class box of A, B is the subclass of A and the parent node of C at the same time. Since A is the outermost layer and the scroll bar is added, the pop-up box C will be covered by A. I tried to set z However, the -index attribute is still impossible to surpass the scroll bar. After Baidu's various questions about the problem of surpassing the parent scroll bar, the query result is impossible. Since it is not possible, there is only other way to go.
Since this design needs to have a similar sliding, the native one is not enough, so just write one yourself. After a while of debugging, the scroll bar is ready:
It seems that there is no problem. Let's test it. When the mouse needs to click on a menu bar, the menu on the left disappears before moving to it. What happened? After analysis, it turned out to be the following analysis diagram:
The problem is found, so continue to change it , I set the z-index to 999 and put its left close to the right ul , then the next effect is as follows:
After testing this is no problem, it is OK up and down, left and right , and then submit the code to the test, just when I feel happy to solve a problem, the test says that other functional modules cannot be clicked and selected, saying that the problem occurred after my code was submitted, Nani? I'll test it myself
They said that this input could not be clicked, and said that it was a problem after adding my code. I couldn't help but snort and thought about the structural analysis diagram of the scroll bar I was doing before:
A is the outermost frame that grows by itself, B is the frame with the same height as the browser, and C is our content, because to do this scroll bar requires a fixed frame to be a div with the same height as the form , and then Then the height of the frame and the height of the outer layer are used to calculate the height of the scroll bar, so B must be in the outer layer of the C frame, so what is the reason for the previous question? The reason is overflow , when the overflow of B When it is set to hidden , then the E box inside will be blocked. This is how I set the B layer.
In this way, the E box will not be covered , so the next problem will come. I will debug it and the B box will print out and the result is the same as I thought.
The vehicle is blocked by the frame of layer B , I just put the z-index of the div of the content on the right on the spot, then it will be like this
FFFFFF..... , then I set the E box to the highest z-index: 999999. No matter how much I fill in later, the height of the box on the right is not as high. Why is this? . . . , and after careful research and analysis, the following conclusions are drawn:
Since A and F are at the same level, the E box is a subset of the A box, and the A box and F are parallel, so the E box cannot be higher than the F box no matter how the height is set . If the A box is set higher than the F box, then the B box will also will overwrite the F box, and the problem is reversed. The annoying words are annoying. I tried adding CSS hover . When the mouse is on the A box, the B box is set to 440px , then the E box has enough space to be displayed. After the user moves out of the A or E box, the B box is set to 210px. In this way, other pages will not be blocked. Now that you have a clear plan, start working. After a while of code tapping , it is written. . . . . But I'm still too young, yes, that's the problem again. . . . . . Above:
When B is set to 440px after passing A; it was originally no problem, the problem is that B inherits from A , that is, when the mouse moves out of A 's return and E 's return is within the range of B , then this style still thinks that you are in A The range class, so B will not be restored to 210px; when the mouse moves out of the range of B , B will be set to 210px; labor and capital will collapse, and Nima will get deeper and deeper. It's really deep in the peach blossom lake .... Since CSS is not the way to go, I will try JS and use the hover event of js to make it, and try it with a little hope:
The result was actually pleasant and the problem was solved perfectly. Looking back at this requirement, I want to laugh a little bit, maybe sometimes it seems that simple things are often pitted there.