Anchors, buttons and inputs

Mixed-up markup

Let's have a look under the bonnet at the markup for Rotten Tomatoes' sign-up form:

<form id="newsletterSignup" action="/promo/newsletter-signup-confirm" method="POST" target="_blank">
  <div class="input-group">
    <input name="email" type="text" class="form-control" placeholder="Enter your email address"/>
    <span class="input-group-btn">
      <button id="footer-newsletter-join" type="submit" class="btn btn-primary-rt" type="button">Join</button>
    </span>
  </div>
</form>

When the 'Join' button is activated, the 'promo/newsletter-signup-confirm' page is loaded, and the email is presumably submitted into an automated sign-up process. (I tried entering 'pony' and the signup-confirm page loaded with an 'invalid email' message.) So, this little sign-up ecosystem on Rotten Tomatoes does the job. But I wonder why they chose <button type="submit"> rather than, for example, <input type="submit">. Would it have made any difference? Let's find out.

Anchors

In The difference between anchors, inputs and buttons, Landon Schropp (2014) argues that the differences between the three elements are semantic. Anchors represent hyperlinks, which are used to navigate to or download external resources. If you want to go to another web page or download something, use an anchor. But what about other uses for anchors?

Anchors as internal page navigation

We can also use anchors to link to sections inside a web page, using the pound sign (#) and an id attribute. For example, this hyperlink, http://getbootstrap.com/css/#buttons, will take the user to a heading with id="buttons". The <a> page on MDN also says that href="#top" can be used to return to the top of the page.

Non-http anchors

Anchors can open up email or telephone apps. For email, use href="mailto:example@email.com. Give emails a suggested subject by adding ?subject=Your%20message. For telephone, use href="tel:+1234567890".

Anchors as toggles

In Responsive Design: Patterns and Principles, Ethan Marcotte (2015) gives an example of a progressively enhanced, responsive navigation menu whose max-height is increased or decreased using an anchor as a toggle (see also my post about the toggling navigation menu, which I've since incorporated into this site). As well as progressive enhancement and responsiveness, does this pattern pass the third of my emerging criteria for evaluating design patterns: accessibility? I'm not sure, but it could probably do with role="button" (discussed below). The role="button" page on MDN mentions that using aria-pressed is also an important step in setting up a toggle, although I haven't played with this myself.

It's possible to prevent a toggle anchor from reloading a page using href="javascript:void(0);". The <a> page on MDN warns that this can lead to unexpected errors if the anchor is copied or opened in a new tab/window.

Anchors as tab navigation

Another way to navigate inside a document is to use a tab structure, such as Bootstrap's togglable tabs. The principle is the same as the toggling menu, above, allowing the user to toggle between content on the same page. The Bootstrap implementation also requires some scripting to implement, this time jQuery, and may not be quite as progressively enhance-able or as accessible.

Anchors as primary key identifiers

Sometimes anchors can have quite form-like behaviour, passing data between web pages. In the PHP section of a course I've been doing by Brad Hussey (recorded sometime in 2015, I think), one of the projects is a dynamic website for a client address book. A MySQL database has a table containing clients' details, and each client is given a unique ID. When you browse the client list, each row has a button which you can click to open an edit page (see Figure 4). These buttons are actually <a> tags with the client id appended to the href, for example href="edit.php?id=1".

In edit.php, you can access the ID using the $_GET array, and then write a MySQL query to retrieve the client's details. For example:

if(isset($_GET['id'])){
  $id = $_GET['id'];
  $query = "SELECT * FROM clients WHERE id='" . $id . "'";
  $data = mysqli_query($connection, $query);
  while($row = mysqli_fetch_assoc($data)){
    // populate the form
  }
} else {
  // error handling
}

This isn't the only way to pass data identifiers between web pages, but it exploits the web's default behaviour without having to resort to JavaScript, so it's good for progressive enhancement.

Non-anchor elements

Why would you ever want to use another type of element, such as a div or span instead of an anchor? I don't know, but if you do then When (and when not to) use an anchor tag?, on CSS-Tricks (2011) suggests the following:

• Style the element with cursor: pointer in CSS
• Add tabindex="0", so that users can tab to it with the keyboard, and
• Define :hover, :active and :focus styles.

Inputs

Inputs come in many different flavours, but the two that I'm interested in here are type="submit" and type="button".

<input type="submit">

A submit input creates a clickable button that submits form data. The target webpage page is specified through the action attribute of the associated form. Setting method="get" transmits the form data through the URL, while method="post" stores the data behind the scenes, in an array. In both cases, the data can be accessed in PHP through the $_GET and $_POST arrays, respectively. You can play around with submit inputs on w3schools.

As Bootstrap shows us, inputs can be styled in exactly the same way as buttons. However, there are even more options available to designers when styling <button type="submit">, as discussed below.

One final point about submit is that it clears the form when you click it. I can't find a resource to verify this, so correct me if I'm wrong. I believe this came up on my PHP course when the form was defined as follows:

<form action="<?php echo htmlspecialchars($_SERVER['PHP_SELF']); ?>" method="post">

This basically ensures that the form data is submitted to the same page, so that it can be validated before taking further actions. If the user entered invalid values and was returned to the page, all the form inputs were reset. Rather than force the user to retype all the data, a workaround was to programmatically update all the form inputs with the data that the user had previously submitted.

<input type="button">

This defines a clickable button with no default behaviour (see <input> on MDN). A typical use for it is to activate a script, such as this example on W3Schools. You need to use the value attribute to control what it displayed on the button.

Buttons

Buttons have three types: submit, button and reset. The first two behave in exactly the same way as inputs of the same time, described above. The difference is that there are more styling options. <button> has both opening and closing tags, unlike an <input>, and you can put almost anything you like inside it, including images, paragraphs, headers and footers. You can also access a button's ::before and ::after pseudo-elements in CSS. The default for type is meant to be submit, but as W3Schools point out it's always a good idea to specify the type attribute because in reality different browsers use different default types.

Chris Coyier proposed an interesting idea on CSS-Tricks (2014). For good progressive enhancement, if you want a button to fire a script, why not inject the button element using JavaScript? This way, if JavaScript is working, great — you get both the button and the script it triggers. If JavaScript is not working, then you get neither; there's no useless button flapping like a vestigial appendage.

role="button"

I mustn't forget to mention role="button". The main purpose of this role is to inform assistive technologies to treat the effected element like a button. That is, when the user interacts with the element, it triggers some kind of in-page functionality, rather than loading another document or web page. The MDN network has this warning about using role="button", though:

Be careful when marking up links with the button role. Buttons are expected to be triggered using the Space key, while links are expected to be triggered using the Enter key. In other words, when links are used to behave like buttons, adding role="button" alone is not sufficient. It will also be necessary to add a key event handler that listens for the Space key in order to be consistent with native buttons.

Nevertheless, when you're styling your buttons in CSS, you can use any of these selectors: button, .button, [type="button"] and/or [role="button"].

Conclusion

That's about my sum knowledge of anchors, inputs and buttons to date. My approach is always to exploit what's already there in HTML. If possible, I try to avoid dodgy practices like overriding the default behaviour of <a> (toggle menu notwithstanding, *nervous cough*…), or using a <p> or a <span> to do the job of a <button>. It's generally bad for accessibility, it requires more time and effort, and 12 months down the line either you or your replacement will have to waste time figuring out what's going on.

So, do you have any strong thoughts about when to use <a>, <input> or <button>? Do you have any tricks or pitfalls you'd be willing to share?