Skip to main content

Command Palette

Search for a command to run...

5 Common Mistakes to Avoid in HTML

Updated
3 min read
5 Common Mistakes to Avoid in HTML
S

A JavaScript enthusiast and a creator who knows how to use Keyboard, Pen, Pencil, and Gamepad to their fullest.

Hello, amazing people. This article will cover few of the common mistakes that we often do while writing HTML. Let's get straight to it.

1. Use of Anchor Elements: <a>

Anchor elements are used to create a hyperlink to a file or a location of a webpage and should always be used for navigating to a real url. Anchor elements are often misused as fake buttons by setting their href to # to prevent the page from refreshing, then listening for their click events.

When we point href value to #, it breaks the default functionality of a link causing unexpected behavior when opening links in a new tab or window, bookmarking, copying/dragging links, or when JavaScript is loading, errors, or is disabled. They also convey incorrect semantics to assistive technologies, like screen readers.

If something is supposed to be clickable, it should always be a <button>

Using here to add a link is not recommended as it doesn't tell anything about where it's going to navigate. Provide some proper text of where the links point to.

Example:

Read more about anchor tag here

Read more about anchor tag on w3school guide

2. Use of Break element: <br>

<br> element is used to break the text in an address or while writing poems specifically. Creating separate paragraphs of text using <br> is not only bad practice, but it is also problematic for people who navigate with the aid of screen reading technology. Screen readers can miss the content between two break elements while still announcing the presence of the tag. This can be frustrating for a person using a screen reader.

Use CSS margin property with <p> element to add space instead.

3. Use of Heading elements: <h1>

  • HTML is a semantic language and anything regarding visuals should be done with CSS only. Avoid using heading tags to resize text. Instead, use the CSS font-size property. Headings use size to indicate their relative importance, but CSS is preferred for general-purpose resizing.
  • Avoid skipping heading levels: always start from <h1>, next use <h2>, and so on.
  • You should only use one <h1> per page.

This is wrong:

<h1>Heading level 1</h1>
<h3>Heading level 3</h3>
<h4>Heading level 4</h4>

This is appropriate:

<h1>Heading level 1</h1>
<h2>Heading level 2</h2>
<h3>Heading level 3</h3>

4. Use of Paragraph: <p>

Do not use empty <p> elements to add space between paragraphs and it is problematic for people who navigate with screen-reading technology. Screen readers may announce the paragraph's presence, but not any content contained within it — because there is none.

If extra space is desired, use CSS properties like margin to create the effect.

5. Use of Aside: <aside>

Aside was introduced with HTML5 and represents content that is not directly connected with the main content. Asides are stand-alone, non-essential as part of an article but when used correctly it can be an extra level of information for your content. Example sidebars or call-out boxes.

Do not use aside to tag the parenthesized test as that is part of the main content. Don’t try to force content into an <aside> if it shouldn't be there.

Example:

<p>My family and I visited The Epcot center this summer. The weather was nice, and Epcot was amazing! I had a great summer together with my family!</p>

<aside>
    <h4>Epcot Center</h4>
    <p>Epcot is a theme park at Walt Disney World Resort featuring exciting attractions, international pavilions, award-winning fireworks and seasonal special events.</p>
</aside>

Writing semantically correct HTML is the responsibility of every developer. I hope you learned something from this article. That's it for now. Take care and stay safe.
Shad

Resources

Illustration on the cover is courtesy of unDraw

A

i read complete html anchor tag .

C

What's wrong with multiple H1 elements?

K
Ken M5y ago

We're all multiple H1 elements on this blessed day.

S

h1 is the most important heading of the page. Suppose you're writing a blog, there can be only one title of the page right? That's h1.

C

Mohd Shad Mirza

Is the H1 the title of the publication or the individual article? What about main feed that shows the last 5 posts; Should those be H1s? Suppose it's a home page for some company like atlassian; would the H1 be "Atlassian" or maybe "Jira" then a second H1 "BitBucket"?

I guess what I'm getting at is there's no real reason to avoid a second H1 as long as it makes semantic sense.

YEARS ago there was an article that said google penalized for multiple H1; but that has long since been the case. When I researched using multiple H1s a year or so ago, that was the single empirical datapoint. No standard, guideline, or publication had any meaningful justification for avoiding multiple H1s other than the defunct Google ranking algorithm.

Screen readers support it.

1
S

Charlie Hayes Having a single h1 is considered as best practice, yes it doesn't hurt your SEO but having one main title makes more semantically.
If I have multiple posts per page, I would probably group them and have a top-level heading h1 while using h2 on the post title.
I'm saying this from the reference of MDN Docs.

C

Mohd Shad Mirza

Declaring something best practice, no matter the authority, does not make it right. The MDN documentation is rather empty on supporting evidence:

You should only use one <h1> per page. Using more than one will not result in an error, but using only one is seen as a best practice. It makes logical sense — <h1> is the most important heading, and tells you what the purpose of the overall page is. You wouldn't have a book with more than one title, or a movie with more than one name! Having a single top-level title is also arguably better for screenreader users, and SEO.

1
A

Thanks for sharing this.

1
S

Glad that you found it helpful. 👏

D

Using <div> tag to write add a piece of text to your webpage, is a valid case when to use <div>?

1
S

Semantically, you should use div when nothing else makes sense.
If you just want to group few elements together and it doesn't make sense to use section, header, footer, main, aside, article, nav, etc then go for div.
Never ever add a text inside a div and use click handler to behave like a button. A div is a container of another item and it should do that only.

P

Good tips for br in p

I would like to add one suggestion on a, try to avoid using target=_blank as it breaks the flow of browsing way more than use of #

In general, like you said, if you need to use only # fro href, try to use button but it is useful as jump to top of page can just be achieved by using # as href

Buttons need more style resets than links and probably that's why I would go for using a[href="#"] as having click handlers on text nodes is less recommended

1
S

Agree, use target=_blank only where needed.
I would consider "jump to the top of the page" as navigation as we are actually navigating the user to the top of the page. Just make sure you take care of "open in new tab" functionality.
A lot of user does right-click and click something from the menu like copy this link or open in new window/tab. That should not break the functionality.

A clickable item can either navigate the user or do some action. If the behavior is not among these or contains both, we probably need to check the UX if it's correct.

P

Personally, I take the thumb rule of "if it looks like link, make it behave as link"

Rest should behave as button.

And when making a button, there are multiple ways to do it.

There are various kind of users and one natural instinct for a user is that if it looks like link, they might try to open in new tab. But that is also vary small percentage of users. Normally the non-tech users will browse in a natural flow where app can guide them in a natural flow.

I personally am a heavy user of open in new tab and I have 4-5 windows with at-least 20 tabs in each. I hate my habit of doing this but yeah it happens.

UX is very tricky thing around this and there is no blanket statement to cover this kind of experience. Every use-case is different and need to be handled with specific Usability Testings

1
S

Pankaj Patel Makes sense

C

Wow nice, and so easy to overlook, even I have made there <br> mistakes before.

1
S

I used to do that too 😅. Thanks for reading. Hope it was helpful.

1
B

Thanks for sharing Shad!

1
S

Thanks for reading 🤝

More from this blog

C

Coding Simplified with Shad

33 posts

Developer, Writer & Artist in same order.