From Scratch Web Games: A Beginners Guide to Game Development using HTML, CSS, and JavaScript

Chapter 5.5: Specialized Text Formats

Just having text input would be all that is necessary for filling out forms, but one of the big pushes for the HTML standard is the semantic web. This is the idea that by providing some information to the page we can make it easier for the web browser and other utilities to be able to better analyse the data on the web page. Understanding what the text being asked to be entered can help the browser in several ways. The easiest example of this is a telephone number.

Telephone numbers are problematic as they differ based on country or region so there tends not to be any standard validation for these. If you know for sure what your region and phone format will be, you can use patterns to enforce this, but pattern matching is very fragile and a change to which regions your site will be used on can break things very quickly. Having a phone number in a text field has another problem, in that it provides no information about what is being entered.

By having a specific telephone number type, this field not only knows what is going to be in it, but the software displaying this field now has more information about the form. This semantics can be used for aiding the user. Some browsers, especially on touch devices, may bring up a phone-style input for entering values here so it is still worth using this type of input when entering phone numbers.

While there is more work involved when creating a form, as you now need to consider the type of text that a field is going to be, this is an extremely minor burden with the benefit that browsers supporting the fields could be doing more work to make sure what the user is entering is correct.

In the git repository, I have a TextFormatsDemo.html that goes over the different types of fields if you wish to play around with them. Let’s take a brief look at the different types of specialized text fields that HTML currently supports. Again, HTML is a living standard, so new fields can be added in the future.

The email input type works just like a text box, but when submitting, the validator expects the string to be formatted just like an email address. As long as the text in the box looks like an email address, it is considered valid. You can use the element’s checkValidity() method to see if the browser thinks the input looks like an email address. Note that empty fields will be considered valid.

Passwords have always been an input type as quite often forms are used for letting users log into a website. The idea here is that we do not want to let people who are looking at the screen when the user is entering their password see what that password is. To prevent this, when the user types the password, it is replaced with asterisks or with dots (depending on the browser you are using). This has been a staple of forms for a long time, but a trend that is starting to happen is that users want to be able to see the password that they are entering. This is not a feature of the browser but can be done by taking advantage of JavaScript. You can change the type from password to text and back again using some simple JavaScript. My sample here just uses text to let you show or hide the password but using eye images would also work.

As you can see, we are taking advantage of the mousedown event to trigger changing the type to text and the mouseup event to return it back to being a password. The code does not have to be embedded into the page as shown here but could be separate functions. An eye icon may work better but I was too lazy to draw an image.

The next type of text box is the hidden type. These are text boxes that are not visible to the user but whose values are sent to the server. This tends to be used by the server to embed information onto the form such as session information.

Phone numbers tend to be very flexible as different parts of the world use different phone numbers, and it is even acceptable to have letters in a number (555-555-PIZZA). Some browsers will bring up phone interfaces for entering these, but the bigger reason you will likely want to use the tel type is for semantic hinting.

The URL type works just like the email type except expecting the string to be formatted like a URL. While it acts like a normal text field the checkValidity() method will let you know if the browser thinks what is entered looks like a URL. Note that some browsers will fail with a site like “www.spelchan.com” but will succeed with “https://www.spelchan.com” which in my opinion, defeats the entire purpose of the validation check.

While I plan on covering numbers in a later section, I will mention them here. Essentially, this is for entering numbers. Many browsers will have up/down controls that let you increase or decrease the number. Another feature that most browsers support for numbers is requiring that the user only enters numbers and a decimal place, making sure that what a user enters is in fact a number.

Finally, the text search option. This really is just a text field but with semantic meaning. It does have one slight difference over the text field in that once you have entered some text, the box will give you an X icon at the end of the box. Clicking on this will clear the box. When having search on a page, this is very convenient for the user.

The demo for this chapter is located on the git repository as “TextFromatDemo.html.”

We now have a form, but it doesn’t stand out. Certainly, we could use CSS styles to clearly place the form inside a box, but older versions of HTML did not have CSS so some special tags were created to do this for the developer. This is very useful and simplifies the amount of CSS needed so we will be looking at fieldsets and legends in the next section.