How not to write templates for bootstrap
Few people are writing a website design from scratch - why, if there are a bunch of great CSS frameworks? The most popular among them is bootstrap. Nevertheless, everyone wants the site to look unique, not like the others - so they often stick over (to the best of possibilities) a free or paid template, or their own UI kit.
I also want to talk about some problems that (unfortunately) occur even in paid templates, not to mention our solutions. The text below does not claim to be unique, and is unlikely to be of interest to experienced developers, but may be useful for novice front-end vendors, web designers and web developers with a wide profile. So, if you're still interested, welcome!
As a rule, if a site is developed over a long period of time, the requirements for its appearance change regularly. If, in addition to this, programmers regularly change on it - then the code (in our case - css) turns into a mess. Somewhere bootstrap classes, template classes in places, all this is diluted with crutches of several generations of layout designers and seasoned with inline styles. Attempts to change something or add new ones lead to long magical games in “guess which classes in which places you need to put in this html block!”. I want to throw everything out and rewrite it from scratch. But I, in fact, looked just to quickly add new fields to the form, I have enough tasks on the backend ... Actually, the reason that prompted me to write this article, we will consider in the first example.
So, we have a standard view of form elements, which we want to change a little, for example, to reduce the height. What are some ways to do this so that the inputs match the UI whale?
You can insert inline styles! It will be so much fun - then copy all this footwoman in every input!
Someone laughs, but I regularly see such decisions. Fortunately, not in this case, but it happens. What happens if we do this? You will have to copy long descriptions of styles into each input, inflating the template and making it less readable.
We will write our own class in which we will describe the necessary height settings, and at the same time we will change the font size!
Yes. This is it. "H40_px-16". From the name of the class is immediately clear what he does? It was about this that I met in my uniform when I tried to understand why the new inputs were slightly thicker than necessary. I looked at the code in the same template, and found it. What consequences await us in this case? In principle, nothing critical. In each class of form elements, in addition to form-control, we will add h40_px-16. Need to memorize, or document. And if the requirement appears all the elements of the form to do with a green background? Just add one more class, “b_g”. And then another ...
Expand existing classes for form elements?
I rarely see this decision, although it seems to me that it is on the surface. And in my opinion - the most correct. This allows us to save on the number of classes that need to be specified in the element, but the most important thing is that it reduces the amount of confusion among developers who are trying to work with this code. If the required change affects all elements of this type, we simply add our own set of rules for form-control, and all inputs change their height, font, background, etc.
In accordance with the UI whale, you need to add to the site an innovative, previously never seen solution! And it is written from scratch. Seriously? No, I can allow this if you are using pureCSS - a good, but minimalistic framework - and you need to implement something that is not included. But if you are using bootstrap - with an extremely high probability you just need to re-read the documentation.
Let's consider an extremely neglected situation in which the site has its own implementation of badges. When the bootstrap is connected. And so, one of the developers who did not participate in the creation of these badges, it was necessary to add them somewhere on the site.
And now let's compare this with the situation when the badge class was redefined for the badge's own implementation, and the color implementation was described in the documentation:
Here we have considered an example when it is necessary not only to change the ready-made solution, but also to expand it, because we are not satisfied with the functionality out of the box (badges in bootstrap3 do not have custom colors). At the same time, it is still the best solution to redefine the existing class, and only after that - add your own.
Of course, the examples I cited are fairly refined, but I actually came across a situation when I looked for the solution first in the bootstrap documentation, then in the documentation for the template used on the site for it (good, there was documentation for it), then I looked for css files where and how the standard behavior was redefined and how the analog was implemented - and as a result, he wrote his styles in order to return (!) the possibilities that were originally.
If you do not want to give your colleagues the pain and want to speed up the work of the team as a whole, when creating your own styles for the site, follow these rules:
All of the above is my personal opinion. I am not a professional front-end developer, and I come across html and css as a rule when I add some new functionality - it’s more convenient for me to immediately tweak the front and back, and then return to combing the design. If your team has established processes, described the rules for good code, compiled guidelines for all developers and everything goes through the code review - you can just laugh at this article, I will not mind. If the article turns out to be useful to someone, it means that I knowingly expounded my muddled thoughts.
I also want to talk about some problems that (unfortunately) occur even in paid templates, not to mention our solutions. The text below does not claim to be unique, and is unlikely to be of interest to experienced developers, but may be useful for novice front-end vendors, web designers and web developers with a wide profile. So, if you're still interested, welcome!
We have historically ...
As a rule, if a site is developed over a long period of time, the requirements for its appearance change regularly. If, in addition to this, programmers regularly change on it - then the code (in our case - css) turns into a mess. Somewhere bootstrap classes, template classes in places, all this is diluted with crutches of several generations of layout designers and seasoned with inline styles. Attempts to change something or add new ones lead to long magical games in “guess which classes in which places you need to put in this html block!”. I want to throw everything out and rewrite it from scratch. But I, in fact, looked just to quickly add new fields to the form, I have enough tasks on the backend ... Actually, the reason that prompted me to write this article, we will consider in the first example.
Input Size
So, we have a standard view of form elements, which we want to change a little, for example, to reduce the height. What are some ways to do this so that the inputs match the UI whale?
You can insert inline styles! It will be so much fun - then copy all this footwoman in every input!
Someone laughs, but I regularly see such decisions. Fortunately, not in this case, but it happens. What happens if we do this? You will have to copy long descriptions of styles into each input, inflating the template and making it less readable.
We will write our own class in which we will describe the necessary height settings, and at the same time we will change the font size!
Yes. This is it. "H40_px-16". From the name of the class is immediately clear what he does? It was about this that I met in my uniform when I tried to understand why the new inputs were slightly thicker than necessary. I looked at the code in the same template, and found it. What consequences await us in this case? In principle, nothing critical. In each class of form elements, in addition to form-control, we will add h40_px-16. Need to memorize, or document. And if the requirement appears all the elements of the form to do with a green background? Just add one more class, “b_g”. And then another ...
Expand existing classes for form elements?
I rarely see this decision, although it seems to me that it is on the surface. And in my opinion - the most correct. This allows us to save on the number of classes that need to be specified in the element, but the most important thing is that it reduces the amount of confusion among developers who are trying to work with this code. If the required change affects all elements of this type, we simply add our own set of rules for form-control, and all inputs change their height, font, background, etc.
Custom solution
In accordance with the UI whale, you need to add to the site an innovative, previously never seen solution! And it is written from scratch. Seriously? No, I can allow this if you are using pureCSS - a good, but minimalistic framework - and you need to implement something that is not included. But if you are using bootstrap - with an extremely high probability you just need to re-read the documentation.
Let's consider an extremely neglected situation in which the site has its own implementation of badges. When the bootstrap is connected. And so, one of the developers who did not participate in the creation of these badges, it was necessary to add them somewhere on the site.
- First, he looks into the bootstrap documentation, and copies the solution from there.
- Seeing that visually it does not correspond to the UI whale, he is looking for documentation on the innovative solution used.
- If this documentation is not (and most likely it is not), it looks for examples of how this is implemented in the code.
- After copying the required beijik class, he sees that the badge is now correct, but blue, and he needs a red one.
- Having found the css file, which describes the classes for the UI of the whale, he discovers that the red color was not laid, and with a sigh adds the class "beijik-red"
And now let's compare this with the situation when the badge class was redefined for the badge's own implementation, and the color implementation was described in the documentation:
- First, he looks into the bootstrap documentation, and copies the solution from there.
- The documentation finds how to add red: badge-red
Here we have considered an example when it is necessary not only to change the ready-made solution, but also to expand it, because we are not satisfied with the functionality out of the box (badges in bootstrap3 do not have custom colors). At the same time, it is still the best solution to redefine the existing class, and only after that - add your own.
Of course, the examples I cited are fairly refined, but I actually came across a situation when I looked for the solution first in the bootstrap documentation, then in the documentation for the template used on the site for it (good, there was documentation for it), then I looked for css files where and how the standard behavior was redefined and how the analog was implemented - and as a result, he wrote his styles in order to return (!) the possibilities that were originally.
If you do not want to give your colleagues the pain and want to speed up the work of the team as a whole, when creating your own styles for the site, follow these rules:
- Check how the necessary functionality is implemented in the framework used (you remember - most likely it is there).
- Find which classes need to be redefined in order to bring the appearance to the desired.
- If the functionality is not implemented, or is not fully implemented, agree with colleagues on a convenient way to extend the functionality, and try to document it for the future.
- If the functionality is needed not everywhere, but only on a specific page - put it into a separate file and connect \ compile it for it (do not need inline styles, please)
Afterword
All of the above is my personal opinion. I am not a professional front-end developer, and I come across html and css as a rule when I add some new functionality - it’s more convenient for me to immediately tweak the front and back, and then return to combing the design. If your team has established processes, described the rules for good code, compiled guidelines for all developers and everything goes through the code review - you can just laugh at this article, I will not mind. If the article turns out to be useful to someone, it means that I knowingly expounded my muddled thoughts.