The body of the

Overflow-y: auto; overflow-y: auto; , place a position: Fixed at the bottom of the page; Fixed button, as follows:

To prevent the body of the page from being obscured by a fixed button at the bottom, the page uses a padding-bottom style attribute. The key layout code and style code look like this:

<body>
	<div class="main">.</div>
	<div class="footer">This is the button that's fixed to the bottom</div>
</body>
Copy the code
:root{-footer-height: 50px;
}
.main {
	padding-bottom: var(--footer-height);
  overflow-y: auto;
}
.footer {
  position: fixed;
  bottom: 0;
  width: 100%;
  height: var(--footer-height);
}
Copy the code

And then I need to add logic A, and when my logic A is satisfied, the bottom fixed button is not displayed, otherwise

This changes the layout of the style, and if I add the A logic, then the padding-bottom property of the.main will have to be removed, so I’ll have to add the style logic as well

It’s fine to add this extra style logic, but it’s not really necessary, and it’s easy to forget when the business logic of the page is complex and the test coverage is not complete, plus if you didn’t write most of the logic on the page

In general, in a project, a fixed button at the bottom is designed as a generic component for the purpose of reusing components, as a component that obviously has a fixed UI specification and can be reused. The generic component is designed to work with the main business page. If it is reversed, I had to write extra judgment style logic in the main business page to use your generic component, which means the generic component is not generic enough

I hope that when I use the bottom fixed button, the component should not affect the rest of my main page, such as the overall style layout, but in fact, for this particular component, the bottom fixed button, I find that many people design components this way

If I were working on the component, I would write:

<body>
	<div class="main">.</div>
	<div class="footer">
		<div class="footer-content">This is the button that's fixed to the bottom</div>
	</div>
</body>
Copy the code
:root{-footer-height: 50px;
}
.main {
  overflow-y: auto;
}
.footer {
  height: var(--footer-height);
}
.footer-content {
	position: fixed;
  bottom: 0;
  width: 100%;
  height: var(--footer-height);
}
Copy the code

There is no need to write a padding-bottom for the.main element to go with the button-holding component at the bottom, because the component will inflate itself

In contrast to the way I wrote at the beginning of the article, I wrote a layer of elements, the extra layer of elements does not set position: fixed; , is an element that occupies real space in the document flow and has the same height as its children, which are the real display and fixed elements. That is, the parent element is responsible for spreading the height, and the child element is responsible for fixing the bottom display

The downside of this approach is that because the bottom fixed child is position: fixed; To set the height of the parent element, you must determine the height of the child element fixed at the bottom

But in general this is not a problem, at the bottom of the fixed element basically in the form of a button, the fixed button at the bottom of the the common component, generally speaking, rounded corners, and the size of the font size, the size is fixed, is nothing more than color and document may need to change, in short height big probability can be determined in advance will not change, direct hard-coded a highly accomplishment

If there is a need to change height, then it is not a problem, it is just an instant measurement

Of course, this method applies not only to the bottom fixed element, but also to the top fixed element

summary

The second trick is actually the result of a personal thought I made a long time ago (as you might expect). Like most people, I used to use the padding-bottom to maintain the relationship between the main page and the fixed button at the bottom, but I once found it annoying to write the padding-bottom all the time. And it didn’t make sense, so I thought about how to make it better, so I added a little trick, right

Write business code also need to be thinking, business code, no technique difficulties, think of is how to ensure the code maintainability of the project, technology selection, component design, structure of decoupling is thinking direction, these things can be hard to reflect on the performance, but at least it is more comfortable to write their own isn’t it?