Click here to Skip to main content
15,072,933 members
Articles / Web Development / HTML5
Posted 16 Aug 2017


6 bookmarked

HTML Buttons for User Interaction Rather Than User Interface

Rate me:
Please Sign up or sign in to vote.
4.73/5 (14 votes)
25 Aug 2017CPOL7 min read
Basic user interaction designs with buttons in Web applications


When developing Web applications, such as E-commerce Website or SPA, you could be making a decision among common good designs for buttons. This article is focused on design choices for buttons in Web applications rather than content Websites.


This article does not discuss the buttons constructed using bitmap typically used in spam banners or special UI systems of computer games.


There exist many articles about buttons in Web pages and applications, discussing the UX from different angles. The writing of this article was prompted by another article "Rediscovering the Button Element" which was quite good, but old, published in year 2007. In year 2017, 10 years on, a lot of things have been changed. And HTML5 has become main stream in browsers across platforms. If you have to take care of some customers who are still using Internet Explorer 6 or 7, probably many of the good advices from older articles may still apply. However, if you are basically using HTML5 for Web applications, you may need some updated information.

Buttons, What HTML Element to Use?

HTML Codes of Buttons

<!DOCTYPE html>
    <meta charset="utf-8" />
    <title>User Interactions of Buttons</title>
    <link rel="stylesheet" 
     crossorigin="anonymous" />
        .body-content {
            margin-left: 2em;
    <div class="body-content">
        <p>Buttons that look alike:</p>
            <button type="submit">ABCD Submit</button>
            <button class="btn btn-primary">ABCD BS</button>
            <button class="btn btn-primary" type="submit">ABCD Submit BS</button>
            <input type="button" value="EFGH" />
            <input type="submit" value="EFGH Submit" />
            <input type="button" 
            value="EFGH BS" class="btn btn-primary" />
            <input type="submit" 
            value="EFGH Submit BS" class="btn btn-primary" />
            <a href="">MNOP</a>
            <a href="" 
            class="btn btn-primary">MNOP BS</a>



In Mozilla Firefox on Windows PC

Image 1

In Safari on iPad

Image 2

In Safari on Mac

Image 3

In Google Chrome on Android

Image 4

As you can see, with bare bone HTML elements without styling, the renderings of element button are looking slightly different across browsers on different platforms, and the rendering in Safari on iPad looks very different from the rendering in Safari on Mac. However, those buttons hooked to Bootstrap are looking identical across different browsers on different platforms, thanks to the great efforts by the Bootstrap team.

Without bootstrap, button [ABCD] implemented with HTML element button and [EFGH] implemented with HTML element input have the same look&feel. So what's the deal?

There has been a school of thinking quite popular:

  • HTML button for buttons
  • HTML input type="button" for form buttons

And in ASP.NET MVC, the scaffolding codes use input type="submit" to submit form data.

Do you think this school of thinking is still valid today?

The short answer is no. You may try the following in W3Schools:

Image 5

In Microsoft Internet Explorer 11, 10, 9 and 8 (released in year 2009) as well as Edge 40, the button element works very well submitting form data.


As of Microsoft Internet Explorer 11 and Edge 40, Internet Explorer and Edge do not support the form attribute of the button element of HTML5.

There are a few fairly good posts in additions to the HTML standards about button and input type="button":

These 3 set of buttons look very alike, basically with the same graphical design. However, when you start to use them, you see the differences:

  1. When you move the mouse pointer hovering over these buttons, you will see that the mouse pointer of MNOP BS will become a hand, indicating that is actually a href link. Obviously, Bootstrap had done a fantastic job in rendering an anchor into a good looking button.
  2. When you right click on each button, you will see button MNOP BS has different context menu which is for a href link.
  3. When you press Ctrl+F to search the button text in the current page, you will find that in Internet Explorer, Microsoft Edge and Mozilla Firefox, the text in button ABCD BS is searchable, while text in button EFGH BS is not searchable. However, in Google Chrome, text in button EFGH BS is searchable.

Are these differences significant to UI design?

I would say these differences are probably insignificant for Graphic User Interface design. However, being aware of the differences may help you to make optimal choices when doing User Interaction design for some contexts, particular in Web applications rather than a content Websites. Which one to choose depends on the contexts, particularly your target users, hardware platforms and the nature of your Web apps.


Bootstrap and alike could also render <div> and <span> etc. into buttons, however, this article won't cover such usages, since in Web applications particularly SPA, <button> and <input type="button".../> are more semantically appropriate.

Rounded Corners or Square Corners?

In some recent conversations with a graphic designer who insisted that buttons should be looking consistently rectangle with zero border radius or square corner across Websites, Web apps and desktop apps of all company's products, I had felt a bit puzzled. While I don't consider myself as a top graphic designer, or top UI designer or top UX designer, however as a Web user, I don't seem to remember any prominent Web company would impose such rigorous consistency. For example, in Gmail's About page, the button is rectangle with square corners:

Image 6

However, inside the Gmail Web app, the buttons have rounded corners mostly:

Image 7

Considering that Google had probably recruited a lot of top UI/UX designers, it should be safe to say that having consistently rectangle with zero border radius or square corners across Websites, Web apps and desktop apps of all company's products is more likely a personal artistic preference rather than a choice based on UI design principles and design patterns.

And if all buttons have to be rectangle with sharp corners, the UI design of button group is broken.

Image 8

As you can see, the buttons in the middle are rectangle with sharp corners, while the left one and the right one have rounded corners. This is likely following the concept and the shape of round bracket which is used in grouping of math expressions.

And this Q&A post "How do rounded corners affect usability?" had explained quite well where to use buttons with rounded corners and where to use buttons with sharp corners.

OK-Cancel or Cancel-OK?

Probably you had done your research on this subject and had encountered a lot of different or even polarized opinions/ideas/advices. Here's an article by Jakob Nielsen, one of the top UI/UX experts in the world:

"OK-Cancel or Cancel-OK? The Trouble With Buttons"

Disabled or Hidden?

For inactive state of a button, there are 2 common UI solutions:

  1. Hidden
  2. Disabled

Pros for Hiding the Button

  • Clarity. Only showing what is needed for current context.
  • Save estate. It allows you to change the controls, using the same space for different means. This is handy when there is a lot going on. Gmail does this.

For example, in Gmail, the Remove button along with other in the button group appears only when you select one or many Email items. And the visual effect is similar to popup menu or context menu.

Image 9

Pros for Disabling the Button

  • Show the action possibility and signal the not ready state of an action. Even if button is inactive, the user has a chance to learn that the action is within current range of possible contexts. And a tooltip may explain the criteria for use.
  • Control location. The user can learn where buttons live within the interface.

In many text editor programs, the Save button is disabled and then enabled if the user has just altered the content.

There could be scenarios where hiding a button and disabling a button are looking equally good. In such scenarios, you may ask yourself some questions:

  1. Is the button to be frequently used within current range of possible contexts?
  2. Is the button an often used button in the well expected positive workflow? Particularly at the completion of the workflow?
  3. Is the button active only when having the workflow being disrupted for some conditions?

If yes for the first and the second questions, the choice between 2 almost equally good solutions go more toward "disabled". If yes for the third question, hiding the button may be a better choice.

For example, in paging, the backward button or forward button is disabled at the first page or the last page.

Image 10


Mozilla Firefox's backward and forward buttons are using the mix of "disabled" and "hidden".

Contexts Do Matter

When choosing, you may ask yourself these questions:

  1. Do you want that the buttons look very alike across different browser on different platforms?
  2. Is your app a SPA or traditional Web app?
  3. Who are your targeted users?
  4. What are your primary targeted hardware platforms?
  5. Do you want one or two buttons to stand out? or you want many buttons to stand out?
  6. ...


For Web applications:

  • Use element button always even in submitting form data, unless you are using some development frameworks like ASP.NET MVC that use input type="submit" by default. And please be aware that Internet Explorer and Edge do not support the form attribute of the button element in HTML5.
  • Use library like Bootstrap or framework like Angular Material for consistent look and feel of buttons across browsers and platforms.
  • Buttons should have rounded corners unless you want to standout one or two, particularly in a portal page.
  • Learn more about your targeted customers, along with other contexts that you should learn and verify.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Software Developer
Australia Australia
I started my IT career in programming on different embedded devices since 1992, such as credit card readers, smart card readers and Palm Pilot.

Since 2000, I have mostly been developing business applications on Windows platforms while also developing some tools for myself and developers around the world, so we developers could focus more on delivering business values rather than repetitive tasks of handling technical details.

Beside technical works, I enjoy reading literatures, playing balls, cooking and gardening.

Comments and Discussions

PraiseFine Details Pin
Bilal Haider10-Sep-17 3:08
professionalBilal Haider10-Sep-17 3:08 
GeneralThanks for updated info Pin
R B26-Aug-17 20:46
MemberR B26-Aug-17 20:46 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.