7 most common web developer mistakes, don't you make them too?

Introduction

I am very happy to help beginners and advanced web developers. I've been thinking about what beginners struggle with most often and what might help them move forward. I certainly don't aim to cover all the problems in this article, but I have focused on the following 7 issues that I see as essential in my experience and also occur a lot.

Inserting an entire library into a project just for one function

Many beginners like a variety of libraries, some of the most well-known being Bootstrap or Bluma. These popular libraries are used everywhere, with no hesitation about whether they fit the project. One such example would be using the entire Bootstrap library just for the sake of Grid System (rows and columns). Another example would be using the jQuery library just for selecting elements in html, when this can be done easily in pure JS.

Too small clickable area

It happens to newcomers that when they create a new interactive element they forget to have enough area for interaction, whether clicking or tapping with a finger. A prime example is the production of "a chevron", which is made of two lines turned opposite each other by a few degrees. This arrow can be made using only html and css. When interaction is then added directly to the arrow itself, the click area is very small and the visitor may have trouble hitting the element.

Inconsistent hover

This problem happens when web developer doesn't have the hover (hover is the state of the element after mouseover) designed by the graphic designer and has to improvise. The developer creates element by element, each of the elements can be created for different lengths of time, and so sometimes a newbie can lose the whole picture of the result of the work, or some feeling of the user using the web page. It often happens that developer assigns elements a hover that he likes, but in the overall picture it can be very disjointed and inconsistent. A prime example might be two buttons, while one of them changes the background color, the other responds with scale.

Missing image alt attribute

The <img> image tag is one of the first things one encounters if one decides to learn HTML. The image tag contains attributes such as the path to the image src="", a description of the image when hovered over title="", an alternate description if the image cannot be displayed alt="", width width="", height height="" and a few others...

But only one of the image attributes is required by the specification, would you know which one?

It is an alt attribute, an alternative description, a piece of text that is displayed as an alternative if the image cannot be displayed in the browser (e.g. wrong path, unsupported format, etc...).

To justify why the alt attribute is so important:

• It provides alternative text for users with visual impairments.
• It helps search engines better understand the content of an image.
• It is displayed if the image cannot be loaded.
• Serves as a replacement for slow loading on mobile devices.

Relative vs Absolute links

Although this may seem trivial from a more experienced developer's perspective, novice developers may have trouble perceiving context by referencing the directory structure. First, let's see what an absolute reference looks like and what a relative reference looks like:

<a href="/index.html">Absolute link starts with a slash</a>
<a href="index.html">A relative reference does not begin with a slash</a>

Absolute link - links directly from the root of the domain, wherever it is used on the site, it will link to the same place. For example, if I use the link on example.com/contact/

<a href="/products.html">Products</a>

It will link to https://example.com/products.html, it simply replaces everything after the domain with my link (/products.html)

Relative link - refers relatively to the place where I am. So if I modify the previous example slightly and use a link on example.com/contact/ */

<a href="products.html">Products (bad link)</a>

It will link to https://example.com/contact/products.html which I didn't want, the products are located at https://example.com/products.html. So relative links work by taking the path (folder) where I'm located - in our case /contact/ */ and putting our relative path at the end of the path, that is products.html and I saw the result above.

We need to be aware of this behavior and write the links correctly. A bitter discovery often occurs when we write links relatively and then put the content in some sub-folder where the relative links stop working because the context has changed, all the resources have a folder above.

Unnamed constants (Magic numbers)

The problem of unnamed constants, can be found in almost every programming language, even in CSS. We can recognize it by encountering a number that has no obvious reason why it is the way it is. They degrade our code readability, are hard to maintain, and can lead to future application errors.

An example of such code can be the following condition in javascript:

function isSmallScreen() {
  if (window.innerWidth > 640) {
  // What does the number 640 mean? Where did it come from?
    return true
  } else {
    return false
  }
}

In the example we see the number 640 used, which is written hard, it is not based on any constant or configuration. Code written this way is usually a sign of small time saving at the expense of very poor clarity.

// File config.js
export {
    Screen: {

    // …
    sm: 640,
    // …

}

// File script.js
function isSmallScreen() {
  if (window.innerWidth > Screen.sm) {
    return true
  } else {
    return false
  }
}

Similarly, we shouldn't use magic numbers in CSS**. Let's demonstrate this with the following example:

.cta-box {
    width: 100%;
    background: #424242;
    margin-top: 273px;
    margin-bottom: 266px;
    padding: 12px;
}

Colors should ideally be defined when we start coding the project and then use colors from the palette, so the color must go into a variable. The margin-top and margin-bottom are problematic, because they are probably somehow generalized numbers and it would be good to at least round them off, ideally to define some spacing variables for each block of the project.

Let's see what the corrected code could look like to make it more readable and systematic:

:root {
    /* Colour definition */
    --bg-secondary: #424242;
    /* ... */
    /* Section indentation */
    --section-spacing-lg: 17rem; /* 272 pixels */
    /* Global indentation */
    --gutter: 12px;
}

/* ... */

.cta-box {
    width: 100%;
    background:var(--bg-secondary);
    margin-top: var(--section-spacing-lg);
    margin-bottom: var(--section-spacing-lg);
    padding:var(--gutter);
}

As you can notice, we have defined variables for color, section indentation and global indentation. All of these values are now defined in one place and we can easily change them.

The code written this way is descriptive, easy to understand and maintain.

!important

There is a !important rule in css that gives more priority to the css styles to which it is applied. However, beginners tend to solve some of their problems this way. Overusing the !important rule then results in very poor orientation, and furthermore the !important rule can only be overridden by the !important rule, so when we need to overload/override such rules the !important rules keep replicating.

Let's illustrate this with an example:

<section>
  <a href="#" class="button">Button</a>
</section>

/* We have defined the background colour of the button */
section .button {
    background: red;
}

/* ... */

/* Somewhere down the line we want to change the color of the button */
/* But we can't because the rule above is more specific */
/* So we use !important */
.button {
    background: blue !important;
}

Let's consider the situation - the developer first defined the button and then in CSS wanted to change the button in the section. However, the top entry has higher element specificity and thus has higher priority, so the developer decided to solve the problem with !important, to say that the bottom rule has higher priority. This way, however, he set himself up for a future problem, because now the background color of the button will not change without using another !important.

So how to override CSS styles correctly?

We need to either reduce the specificity of the rewritten rule or increase the specificity of the newly created rule, for example like this:

/* We have defined the background colour of the button */
/* in the same way as in the first example */
section .button {
    background: red;
}

/* ... */

/* But here we increase the specificity */
/* so we don't have to use !important */
section .button {
    background: blue;
}

The advice for this issue is avoid the `!important' rule, but there are rare cases where this is unavoidable. (For example, in some cases when working with third-party libraries that we can't touch)

Conclusion

I'm sure there are many other things to watch out for, the ones I mentioned in the article I consider basic and every frontend user should know them. It's great that you've read this far and I'll be very happy if you share this article among your frontmen** either in your company or friends, maybe some of the above will be interesting for them too :)

Useful links

• CSS Specificity Calculator
• Magic Number Problem on Wiki
• Article on collaborating with a graphic designer