Lars

Posted on Mar 23, 2023 • Edited on Mar 25, 2023

10 HTML, CSS & JavaScript mistakes which are made by beginners 🫶

#webdev #javascript #beginners #selftaught

As a beginner in web development, it's easy to make mistakes when working with HTML, CSS, and JavaScript. Here are ten of the most common mistakes i did as an self-taught developer in my first weeks and how to avoid them:

1. Using invalid HTML tags:
Using invalid HTML tags or open/close typos can cause issues with the functionality of your website. For example, using

<center>

instead of

<div text-align="center">

is invalid HTML. Validate your HTML with your IDE features or Plugins.

2. Incorrect use of semantic HTML elements:
Using the wrong HTML element can make your code less understandable for browsers and search engines. For example, using

<div>

instead of

<header>, <main>, <footer>

can affect accessibility and SEO. Use semantic HTML elements to improve your code's meaning and structure.

3. Inline styles:
Using inline styles can make your code harder to maintain and modify. For example, using

<p style="color: red;">

instead of a CSS class for styling text is not recommended. Instead, use external CSS files and classes to apply styles to your HTML elements.

4. Not designing for responsiveness:
Not designing for responsiveness can result in poor user experience on different devices. For example, not using CSS media queries to adjust the layout of your website for smaller screens is not recommended. Also start with mobile first, it's much harder to refactor from a desktop size down to mobile.

5. Overusing fonts and colors:
Overusing different fonts and colors can make your code harder to read and maintain. For example, using too many different font sizes or colors can make your CSS file bloated and harder to navigate. Instead, stick to a few consistent choices for your fonts and colors.

6. Choosing the wrong image format or resolution:
Using the wrong image format can affect the loading times and quality of your images. For example, using a PNG file for a photograph can result in a large file size and slow loading times. Use JPEG for photographs and PNG for graphics with transparency. You can also try WEBP a newer format for the web (thanks to @joelbonetr).

7. Not optimizing JavaScript files:
Not optimizing JavaScript files can affect the loading times of your website (modern frameworks can handle this for you). Use minified and combined JavaScript files to improve your website's performance.

8. Not commenting enough:
Not commenting enough can make it harder for you and others to understand your code later on (specially yourself if you jump back after some weeks or months). For example, not explaining the purpose of a complex function can make it harder to modify, understand (again) or debug. Use comments to explain your code and make it more readable.

9. Writing invalid CSS:
Writing invalid CSS can result in unexpected behavior on your website. For example, using an invalid selector like

<p color="red">

instead of a valid one like

p { color: red; }

can result in broken styles.

10. Not prioritizing accessibility:
Not prioritizing accessibility can make your website less usable for people with disabilities. For example, not using descriptive Alt attributes for images can make it harder for visually impaired users to understand the content. Use semantic HTML tags and test your website for accessibility using tools like Lighthouse. If you don't care about accessibility, you will block people to enjoy our 🏳️‍🌈 web.

Let me hear what typical mistakes you made in the beginning?

Cheers! Code healthy, happy an enjoy it ❤️.

Top comments (13)

JoelBonetR 🥇 • Mar 24 '23

Hi Lars, nice catch up!

Just pointing out an issue in the text:

Use JPEG for photographs and PNG for graphics with transparency.

The recommendation though, would be to use webp format on both cases.

Best regards 😁

Tracy Gilmore • Mar 25 '23 • Edited

I would also suggest that SVGs have a specific role (diagrams, animation etc.) but I am no expert. "I just love SVGs".

JoelBonetR 🥇 • Mar 25 '23

Hahaha indeed they do!

SVGs have it's pros and cons, dealing with them is somewhat more difficult than images, just to clarify, SVGs are not images (representation of things through pixels) but Scalable Vector Graphics, which is super nice for logos and different stuff you need to scale depending on the client's device but annoying in certain situations (e.g. catalogs/product pictures)😁

Best regards!

Tracy Gilmore • Mar 25 '23 • Edited

Hi Joel,
I am not sure I agree with the statement "SVGs are not images". I think that requires a very specific definition of the word 'image'. Possibly you mean they are not raster but vector graphics, in that you would be absolutely correct.

SVG files can be loaded and presented in the browser using an <img> element, so I do not really see much of a difference. For some graphical representations they are superior to PNG but they are not a panacea (one-stop shop) for all graphics. As you say, they have pros and cons.

JoelBonetR 🥇 • Mar 25 '23 • Edited

Absolutely Tracy, I've failed to use the correct wording (e.g. digital image file, bitmap/rasterized or any other), thanks for pointing it out! 😄

Lars • Mar 24 '23

Hi Joel,
thanks for your feedback, i have added your suggestion as well as left you credits for it in the article 😉

JoelBonetR 🥇 • Mar 24 '23

Anytime! 😁
Thank you for the attribution as well 😃

Tracy Gilmore • Mar 25 '23 • Edited

Hi Lars, All good point but I would like to discuss a couple.
8, Commenting has become a slightly contentious point. "To comment or not to comment..." following Uncle Bob's (Robert Martin) advice on Clean Code. Commenting is not a bad thing but it should be applied with care and describe what the code does not. For example:
const MONTHS_IN_A_YEAR = 12; does not need a comment. That said, if you need a comment because what the code is doing is not obvious, it could be an indication the code needs to be refactored/simplified.
10, Your point is correct, of course Accessibility (A11y) is important. In fact it gets more important as you get older, believe me! But IMO it is a mistake to apply a blanket mandate on the level of accessibility to be applied. I am speaking as an application developer rather than web site (content) creator but WCAG is still an essential set of rules to go by. However, we should not state "All applications need to be AA conformant", and we should definitely not mandate AAA conformance. Instead, I suggest the end-user needs should be assessed and targeted. There is no point in making an application (such as an image editor tool) screen-reader friendly if it is reasonable (supported by evidence) to assume there is little to no demand for it; it is just extract cost and complexity. I have not seen figures to support my assumption but, I think it is fair to assume (especially as each conformance level of WCAG builds on the previous) that each A of conformance is something in the order of a magnitude (x10) greater in cost, which is just one of the reasons AAA should off the table and AA+ should be managed with care.

Finally on the topic of "semantic HTML elements", don't forget other elements like:

<aside>, <nav>, <section>, <article>, <dialog>, <menu>

and others. Check out MDN. Using semantic (HTML) markup goes a long way to aiding A11y.
Regards, Tracy

Lars • Mar 28 '23

Hey Trancy,
thanks for your comment 🙏
your mentioned points are correct. However, there is one crucial thing in which we should expand our awareness. Yes mostly the acceptance criteria say there will be no users with restrictions (business or personal). However, this is also because from the beginning these groups of people are excluded. If I do not consider you as a person for my app from the beginning, you also never have the possibility to be a user or may be.

Can we as developers prevent this all? No, but we can do some things to create a more accessible web and consider or implement small things, even if it is not required.

Peace ✌️