Anchors, buttons and inputs
Tags: Bootstrap HTML PHP
Recently, I've been learning about handling HTML form data with PHP. Add a few inputs and a submit button, give the form a method (
POST), tell it where to send the data (using the
action attribute), and make sure to include some validation to prevent the user from breaking your site. No sweat! While I was looking at the mark-up for Rotten Tomatoes, I started thinking about its newsletter sign-up form, which appears in the footer of each page (see Figure 1).
Rotten Tomatoes is built on the back of the Bootstrap framework, which has an attractive set of styles for its form elements, including inputs (
class="form-control") and buttons (
class="btn"). The thing with Bootstrap's buttons is that web designers are encouraged to style several different elements—anchors, buttons and inputs—to look the same (see Figure 2). So my question for this post is how is a rookie web designer to know which of these elements to use?
Let's have a look under the bonnet at the markup for Rotten Tomatoes' sign-up 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.
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.
Anchors can open up email or telephone apps. For email, use
href="mailto:email@example.com. Give emails a suggested subject by adding
?subject=Your%20message. For telephone, use
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
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
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:
Why would you ever want to use another type of element, such as a
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: pointerin CSS
tabindex="0", so that users can tab to it with the keyboard, and
Inputs come in many different flavours, but the two that I'm interested in here are
A submit input creates a clickable button that submits form data. The target webpage page is specified through the
action attribute of the associated
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
$_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:
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.
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 have three types:
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
::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.
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:
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
<button>? Do you have any tricks or pitfalls you'd be willing to share?