Why we should choose AWS over any other cloud Provider

10 min readAug 6, 2021

Let’s be real here for the second. As we go deeper into web development, we become better and more experienced developers. But often we make some mistakes. Today we are going to talk about the top 14 mistakes that most of the developers do while programming

Let’s get to know me quickly. Hi, I am Anand. I am a full stack developer and cyber security enthusiast. I always try to learn new things, and want to reach out to you with this information.

Cascading Style Sheets (CSS) is one of the most important pillars holding a webpage together. It gives you the power to bring a sense of style and design into a simple HTML layout. From font families and colors to alignment and display, it does it all.

Most of the time we do not care about small things in CSS, but we should know that they are very important for us. On top of that, it is unarguably one of the simplest and most intuitive languages to work with. It’s make our web page interactive and responsive.

Here, I have listed some common mistakes that most web developers make while writing CSS code, we will also talk about how to identify those mistakes and avoiding them can help you write better and more efficient CSS.

1. Not using fallback fonts

In this world of web development, it doesn’t matter how pretty a particular font makes your page look, or how much attention it is garnering, you always have to consider that not all font types are supported by all computers. If you are using a font that some browsers do not support, it means that your web page may not be as beautiful and attractive as you are designing it for all users.

You have to accept this. Because you can also take such a font, which supports all browsers in all computers.

I’m not saying that you should not use good fonts. But at least use fonts that work in almost all systems.

So, after using your favorite font, say Helvetica, always make sure to list the fallback fonts that the browser can use in case it is not supported.

Instead of writing this,

#text{
  font-family: Helvetica;
}

expand the code by font fallbacks such as:

#text {
  font-family: Helvetica, Arial, sans-serif;
}

Now, even if the browser doesn’t support Helvetica, it would fall back to the second most preferred option Arial before going to the browser default.

2. Hard Coding px Instead of Relative Units

Although it is sometimes necessary to use absolute px values, you should always use relative measurements such as em, % (percentage), rem (root-Em), and others whenever possible.

This ensures that the website scales proportionally to the user’s choice of zoom level and screen/browser size.

So, instead of declaring the size as absolute,

.text {
    font-size: 16px;
    line-height: 20px;
    margin-bottom: 8px;
}

do this :

.text {
    font-size: 1rem;
    line-height: 1.25em;
    margin-bottom: 0.5rem;
}

3. Using Color Names Instead of Hexadecimal

when you say color: red; You are essentially asking the computer to show that whatever color it thinks is blue. By doing this, you are giving the browser control over how your web page should appear, and as a developer, this is something you should never do. By vaguely naming the color red, it can easily differ from the shade of red you have in mind, and worse it can also vary from browser to browser.

Using hexadecimal values e.g. Color: #FF0000; So it becomes something that all developers should adopt. It ensures uniqueness, is supported by all browsers, and gives you control to decide how you want your web page to be displayed.

Note: An efficient way to find and use hexadecimal values is to first enter the color name closest to the desired color, and then inspect the element to find the hex value using the color dropper.

4. Redundant Selectors

My process for writing styles is to start with all the typography, and then work on the structure, and finally styling all the colors and backgrounds. That’s what works for me. Since I don’t focus on just one element at a time, I usually find myself accidentally typing a redundant style declaration.

I always do a final check after I’m done to make sure I haven’t repeated a selector; And if I have, I will merge them. It’s okay to make a mistake like this when you’re developing, but just try to make sure they don’t make it in production.

Check out this list of CSS optimizers that can help you automate the search for inefficient and redundant selectors.

5. Over Qualifying Selectors

Like everything else in redundancy, too much specificity is a bad thing. And more often than not, it’s not even necessary. Take a look at the CSS below:

header #nav ul li a {...}

First, the header specification is absolutely unnecessary because the ID with the highest specificity has already been used (IDs are unique and associated with only one element). Furthermore, an unordered list (ul) always contains list items (li). So it becomes pointless to mention it. The same selector can now be written as:

#nav ul a {...}

There are only two levels of specificity with CSS — specific and not specific enough. Including all those extra elements may make it look ‘safe’ but are really unnecessary and are only adding to the length of your stylesheet.

As a general rule, your selectors should be as short as possible. Be as specific as you need to get the job done.

6. Using ID’s instead of Classes

The most cogent argument against using ID’s is that it has a much higher specificity than classes, which is why it becomes hard to overwrite and extend your styles. A class on its own can’t overwrite styles belonging to an ID. To “beat” the ID, you would need either more IDs or to use !important, which can begin specificity wars in your stylesheets.

Class selectors can also be used for several HTML elements on the same page, unlike IDs which are unique to each element. Being able to reuse styles is one of the advantages of CSS.

To maintain a consistent convention, use only the class attributes to define styles and IDs while integrating interactivity with Javascript instead.

7. Not Using CSS Reset

If you have ever displayed an HTML page with no CSS styling, you know that the web browser itself “styles” the page using some default values as a fallback. The text has a particular font size and style, the margin and padding are set to certain values.

While this is a good thing for someone who does not use CSS, it is important to first reset these values when you put your own styles into the page. These values vary from browser to browser, hence a CSS Reset is the only way to ensure that all your styles are uniform and effective.

This entails resetting all the styles of all the HTML elements to a predictable baseline value. Once you do this, you can style all the elements on your page as if they were the same to start with. A blank slate.

An easier but incomplete way to do this is by resetting the margin and padding using a universal selector:

* {margin:0; padding:0;}

For a complete reset, however, you can use the Eric Meyer reset (modifying it as per your choice), to reset borders, underlines, and colors of elements like list items, links, and tables so that you don’t run into unexpected inconsistencies between web browsers.

8. Repetitive Code (Redundant Selectors and Properties)

In general, repeating yourself while coding is not considered a good practice. CSS is no different. Take a look at the code below:

#selector-1 {
  font-style: italic;
  color: #e7e7e7;
  margin: 5px;
  padding: 20px
}
.selector-2 {
  font-style: italic;
  color: #e7e7e7;
  margin: 5px;
  padding: 20px
}

A better way to write this is by combining them, with the selectors separated by a comma (,):

#selector-1, .selector-2 {
  font-style: italic;
  color: #e7e7e7;
  margin: 5px;
  padding: 20px
}

This is not just more efficient, but also reduces maintenance time and page-load speed.

9. Not Separating Design from Layout

The job of CSS is to provide styling, and the job of HTML is to provide structure. Generally, HTML should be written in a way that captures the information hierarchy of the page, ignoring any design concerns. Afterward, CSS can be added to make things ‘look nice.’

However, while HTML provides structure, it cannot always position elements on the exact spot of a page you want it to appear, which is where we use CSS to scaffold the layout of the page. Once an element is put into the right place on the page, it’s easy to style it without worrying about the display and position. This is why Layout CSS should be separated from Design CSS.

Instead of putting the layout as well as design properties together,

.article {
  display: inline-block;
  width: 50%;
  margin-bottom: 1em;
  font-family: sans-serif;
  border-radius: 1rem;
  box-shadow: 12px 12px 2px 1px rgba(0, 0, 0, .2);
}
.sidebar {
  width: 25%;
  margin-left: 5px;
}<div class="article"></div>
<div class="article sidebar"></div>

Separate the design and layout of elements:

/* layout */
.article, .sidebar {
  display: inline-block;
}
.article {
  width: 50%;
  margin-bottom: 1em;
}
.sidebar {
  width: 25%;
  margin-left: 5px;
}/* display */
.card {
  font-family: sans-serif;
  border-radius: 1rem;
  box-shadow: 12px 12px 2px 1px rgba(0, 0, 0, .2);
}<div class="article card"></div>
<div class="sidebar card"></div>

This ensures separation of concerns, which is a common software engineering principle that helps keep our code maintainable and easy to understand.

10. Writing Unorganized CSS

Instead of writing your styles just as you think of them, do yourself a favor and organize your code neatly. This will ensure that next time you come to make a change to your file, you’re still able to navigate it.

Comment your CSS: A good tip is to add a block of comments between logical sections in your stylesheet too, to help locate different sections quickly when scanning through, or even give you something to search for to jump right into that part of the CSS. You don’t need to comment every single thing in your CSS, as much of it will be self-explanatory. What you should comment are the things where you made a particular decision for a reason.
Create Logical Sections in your Stylesheet: It is a good idea to have all of the common styling first in the stylesheet. This means all of the styles which will generally apply unless you do something special with that element. You will typically have rules set up for body, p, h1, h2, h3, links, and tables. After this, you can have a few utility classes, or properties, things you know you will want to apply to lots of different elements. Finally, include CSS for specific things, broken down by the context, page, or even component in which they are used.

11. Redundant Properties

Similar to the one above, I often find myself having to apply the same properties to multiple selectors. This could be styling an <h5> in the header to look exactly like the <h6> in the footer, making the <pre>‘s and <blockquote>‘s the same size, or any number of things in between.

In the final review of my CSS, I will look to make sure that I haven’t repeated too many properties. For example, if I see two selectors doing the same thing, such as this:

#selector-1 {
  font-style: italic;
  color: #e7e7e7;
  margin: 5px;
  padding: 20px
}
.selector-2 {
  font-style: italic;
  color: #e7e7e7;
  margin: 5px;
  padding: 20px
}

I will combine them, with the selectors separated by a comma (,):

#selector-1, .selector-2 {
  font-style: italic;
  color: #e7e7e7;
  margin: 5px;
  padding: 20px
}

I hope you’re seeing the trend here: Try to be as terse and as efficient as possible. It pays dividends in maintenance time and page-load speed.

12. Not Providing Fallback Fonts

In a perfect world, every computer would always have every font you would ever want to use installed. Unfortunately, we don’t live in a perfect world. font-face aside, web designers are pretty much limited to the few so called web-safe fonts (e.g. Arial, Georgia, serif, etc.).

There is a plus side, though. You can still use fonts like Helvetica that aren’t necessarily installed on every computer. The secret lies in font stacks.

Font stacks are a way for developers to provide fallback fonts for the browser to display if the user doesn’t have the preferred font installed.

For example:

#selector {
  font-family: Helvetica;
}

Can be expanded with fallback fonts as such:

#selector {
  font-family: Helvetica, Arial, sans-serif;
}

Now, if the user doesn’t have Helvetica, they can see your site in Arial, and if that doesn’t work, it’ll just default to any sans-serif font installed.

By defining fallback fonts, you gain more control as to how your web pages are rendered.

13. Unnecessary Whitespace

When it comes to trying to reduce your CSS file sizes for performance, every space counts. When you’re developing, it’s OK to format your code in the way that you’re comfortable with. However, there is absolutely no reason not to take out excess characters (a process known as minification) when you actually push your project onto the web where the size of your files really counts.

Too many developers simply don’t minify their files before launching their websites, and I think that’s a huge mistake. Although it may not feel like it makes much of a difference, when you have huge CSS files, it can improve your Page Responsive time

14. Not Organizing Your CSS in a Logical Way

When you’re writing CSS, do yourself a favor and organize your code. Through comments, you can insure that the next time you come to make a change to a file you’ll still be able to navigate it.

How you choose to organize your styles is completely up to you, . I personally like to organize my styles by how the HTML that I’m styling is structured. This means that I have comments that distinguish the header, body, sidebar, and footer.

A common CSS-authoring mistake I see is people just writing up their styles as soon as they think of them. The next time you try to change something and can’t find the style declaration, you’ll be silently cursing yourself for not organizing your CSS well enough.

Thank You ❤️