Can you see the "Promoted” caption in the background below job ads? Let’s imagine that we start coding this section, and we have already styled our h1 tag to look exactly as “Promoted”. So should we use h1 for it? The answer is NO. The title that describes this section is “Promoted offers” and the big piece of text in the background that reads “Promoted” is only a decoration which can fit into the usual div.
Now, the question is how to make use of the h1 that we have already styled. What I recommend here is adding extra class selectors to every heading selector. You can turn this:
Now you can use .h1 and .h2 classes to make things look like headings without interfering with SEO.
Everything works fine, but imagine that two weeks later we add three more buttons to our website, and all of them should look like just like the one for the newsletter. It would be strange to use the .btn--newsletter class for those new buttons, since they have nothing to do with the newsletter. The recommended course of action in such case would be to refactor this:
Then apply .btn--green to all the buttons. Now guess what will happen to the newsletter button.
If you think that the newsletter modal will no longer show up after the newsletter button is clicked, you’re 100 percent right. How can we fix that and prevent similar situations in the future?
Not Removing Redundant Styles
Sometimes, I have the opportunity to do a code review for newbie developers, and an error they make quite often is leaving redundant code that does nothing.
I can point out three typical frontend mistakes here.
Having display: block in selectors that have a float property other than none (if we float an element in any direction it becomes block)
Having width: 100% on a block element (blocks take 100% width by default)
Overriding a property in a single selector
Embedding Fonts in a Wrong Way
I noticed that many developers tend to misunderstand how @font-face should be used. They do not specify font-weight and font-style in their @font-face declarations and control those properties via the font-family property.
Let’s analyse a case with this particular error:
This code assigns Averta to the elements by adding font-family: 'Averta-Regular' to their CSS selectors, but if we add font-family: 700 either nothing will happen, or we will see false boldness that came about as a result of processing a regular font by the browser. The only way to achieve displaying Averta in bold is having font-family: 'Averta-Bold' in the styles for the given element.
We can easily fix that, just make the font-family’s value the same in @font-face declarations and add adequate font-weight properties:
Now we can easily use this font just like the usual ones:
We can do the same with font-style if we have separate font files for different styles.
Not Abstracting Elements
Abstracting elements in CSS is the process of turning child elements into standalone elements. Below you can see the newsletter section taken from our company’s website.
In Netguru, we use BEM so our HTML could look like this:
Let’s imagine that a week later, we have to place a heading identical to the one above in another section on another page. The proper approach to this would be making .newsletter__title a standalone element, so we’ll move the CSS properties from .newsletter__title into e. g. .section-title. Eventually, the HTML for our newsletter will look as follows:
We’ll be able to use the .section-title module wherever we want, even outside the .newsletter module.
We can make our workflow better by predicting those situations and abstracting elements in advance. When to abstract? Every time you think that a child element will be used outside its parent in the future – abstract it.
Not benefitting from the Goodness of Flexbox or CSS Grid
Flexbox solves countless problems, and it’s pretty easy to benefit from it (unless you have to support IE9 or lower). I often see developers struggling with floats and inline-blocks, while they could use flexbox or the CSS grid property and do the same things five times faster, cleaner and easier.
The first time you use it, flexbox can be confusing, and this is probably the reason that some people try hard not to learn it, but trust me – it’s super worth it. Just find any interactive tutorial (there is plenty of them out there), give it no more than 3-4 hours, and you will be a flexbox pro. I would recommend Flexbox Froggy – it’s sheer fun to go through it.
If you’re not sure yet, make sure you check out Solved by Flexbox, a project created by Philip Walton, where he explains what can be achieved with flexbox that used to be impossible/hard to do without.
Uppercasing Things in HTML
When we have to code a section’s title e. g. “JOB ADS” we have two options to make it uppercase. The first of them is to write it exactly like this in the HTML:
In most cases, it’s the wrong way. Our second option is to use the text-transform CSS property:
Why was the first option wrong? The division between HTML and CSS is about the separation of the document structure and the presentation layer. This title’s being uppercase belongs to the presentation layer, so we should definitely do this in CSS.
Still, we have to remember that there are cases where uppercase words in HTML are the right way to go, for example when you quote someone shouting something.
The most popular frontend mistakes result from carelessness.
Programmers tend to finish their tasks as quick as possible, but if they don’t think about the future and prepare unscalable solutions, they are going to pay for it later by spending time on refactors that cost money.
All of the frontend mistakes presented above are very common and could easily be solved by applying the techniques from this article. If you’re an experienced front-end developer form a good web development company and already know these tricks, you can send the article to the back-end developers working at your company. I’m quite sure they sometimes need to change something in the front-end, and it would save them a lot of time if they could do it by themselves.