HTML5 for web designers. Part 4: Forms 2.0

HTML5 for web designers

1. Brief history of markup language
2. HTML5 model
3. Multimedia
4. Forms 2.0
5. Semantics
6. HTML5 and modern conditions

When browsers began to support JavaScript, two main tasks were quickly fixed to it: hover effects and improvements for web forms. Then a pseudo-class appeared in CSS : hover, and the need for scripts for many of the foreground situations was gone.

This story is constantly repeated. As soon as a certain template or task becomes quite popular, they are almost certainly ultimately simplified technically and made more accessible. This is how many functions appeared in CSS3 for creating simple animations, which previously required JavaScript.

Speaking of forms, here the possibilities of CSS are rather limited. And now HTML5 comes onto the scene again. Following the same principle, he introduces new features that are not really new, but made easier and more convenient.
')
It is not hard to guess that they were previously part of a separate WHATWG specification called Web Forms 2.0.

Stub text

There is a common pattern for the design of search forms:

1. If the field is empty, insert a blank text into it.
2. When the field is in focus - remove the cap.
3. If the user left the field blank and removed the focus, return it.

In this case, the stub is usually highlighted in a slightly lighter color than the text entered in the field, which is achieved using CSS, JavaScript, or a combination of both.

In HTML5, all this is implemented using a simple placeholder parameter:

<label for="hobbies">Your hobbies</label> <input id="hobbies" name="hobbies" type="text" placeholder="Owl stretching"> 

So it will look in the browser. Owl stretching is the default text given as an example.

In those browsers that support this attribute, it works fine, but so far there are not so many of them. You decide what to do with the rest. In principle, you can not strain and do nothing at all - this function is still convenient and pleasant, but not vital. But as an option, you can develop a JavaScript alternative; in this case, you first need to make sure that the browser really does not support placeholder .

Here is an example of a simple function that checks the support of a specific parameter:

 function elementSupportsAttribute(element,attribute) { var test = document.createElement(element); if (attribute in test) { return true; } else { return false; } } 

It creates a “phantom” element in memory — not on the page itself — and then looks to see if the prototype of this element has a property with the same name as the parameter that you are testing. The function returns either true or false .

With it, you can slip the alternative code only for those browsers that do not support this HTML5 feature:

 if (!elementSupportsAttribute('input','placeholder')) { //    JavaScript  . } 

Autofocus

“Hi, I have autofocus function. I know you from roles like Google: I'm lucky and Twitter: What's happening? "

This template is very simple and relatively easy to implement in javascript. Its essence is that when the page is loaded, you need to automatically put the focus on a specific field.

HTML5 allows you to use the autofocus boolean option for this:

 <label for="status">What's happening?</label> <input id="status" name="status" type="text" autofocus> 

The only problem is that this feature can be terribly annoying. Very often, flipping through pages on the Internet, I use the space bar to scroll quickly through the contents. On sites like Twitter with this autofocus, I often find that instead of scrolling, I fill the field with spaces.

The logic of why this parameter is included in the specification is quite clear, but it is not perfect in terms of usability. Therefore, I advise you to use it carefully and only in the case of obvious benefit and with minimal likelihood of inconvenience.

One of the advantages of shifting the role of executing this function from scripts to markup is that, theoretically, users can disable it in the settings of their browser. No browser, however, does not allow it yet, but still ahead. Anyway, now it can be disabled only along with JavaScript in general - not the best solution; it's like gouging out your eyes to avoid too bright light.

Just as with the placeholder parameter, you can check for autofocus support in the browser and, if necessary, add alternative JavaScript code:

 if (!elementSupportsAttribute('input','autofocus')){ document.getElementById('status').focus(); } 

The autofocus parameter can be applied not only to input elements, but to any other field types, such as textarea or select . And, of course, only once on the page.

Required

JavaScript is often used to check the form on the client side. Again, part of this task is now shifted to HTML5. Now you can specify that a specific field is required to be filled with the required boolean parameter.

 <label for="pass"> </label> <input id="pass" name="pass" type="password" required> 

Theoretically, the presence of an empty field with this parameter should itself prevent the user from sending data for processing. But while the browsers do not do this yet, it can still be integrated for the usual processing of forms with JavaScript. Just now instead of selecting elements by, say class = "required" , you can search for them by the specifically required parameter.

Autocomplete

Modern browsers do not simply display web pages, but also try to increase usability, security and usability. The form auto-complete function is an example of this approach. Most of the time it is quite useful, but sometimes it can be a little annoying or even a potential security risk. I don’t mind when the browser remembers my contact details, but I wouldn’t want it to store the login and password of my bank account in case the computer is stolen.

HTML5 allows you to disable autocomplete for both a specific field and the whole form. The autocomplete parameter is not boolean, although it takes only two values: on and off .

 <form action="/selfdestruct" autocomplete="off"> 

By default, it is set to on , thus allowing browsers to use autocomplete without restrictions.

As already mentioned, it can also be added to the selective fields:

 <input type="text" name="onetimetoken" autocomplete="off"> 

In this case, there is no JavaScript alternative, so this function is not a simplification of existing models, but a new thing that works directly with browser features.

It may seem strange that it was included in HTML5, given that it is not very common. But it is fully justified, taking into account the security risk that may be hiding behind autocomplete; so now you can turn it off if necessary.

Datalist

The new datalist element allows the standard input to be crossed with the select element. By adding the list parameter, you can then create a list of predefined choices:

 <label for="homeworld">  </label> <input type="text" name="homeworld" id="homeworld" list="planets"> <datalist id="planets"> <option value=""> <option value=""> <option value=""> <option value=""> <option value=""> <option value=""> <option value=""> <option value=""> </datalist> 

This allows users to select an option from the list or add their own if it is not there. It is very convenient for situations in which you usually need to insert an additional field “Other, please specify below.”

Convenient hybrid.

If the browser does not support datalist , this field will function as normal input .

New input

The type element of the input element has been significantly extended in HTML5. There are so many trodden trails that need to be tiled, just like building a network of highways on a mushroom site.

Search

The input element with the search value in type works in the same way as the one with the text value.

 <label for="query"></label> <input id="query" name="query" type="search"> 

The only difference is that for search it is assumed that the browser will display the field a little differently, adhering to the general style of the search fields in the operating system.

So this, for example, makes Safari.

Contact details

There are three new values ​​for the type parameter for different types of contact information: email addresses, websites and phone numbers.

 <label for="email">Email</label> <input id="email" name="email" type="email"> <label for="website">-</label> <input id="website" name="website" type="url"> <label for="phone"></label> <input id="phone" name="phone" type="tel"> 

Again, they will behave in the same way as usual imput, with the difference that browsers now have a little more information about the data that needs to be entered there, which can be useful.

Safari announces support for these new field types, but at first glance they do not look any different from those with type = “text” . However, if you experience them in Mobile Safari - that on Apple mobile devices - the difference will become noticeable. The appearance of the on-screen keyboard will be different for different fields:

New types of imputs in Mobile Safari.

Trifle, but nice.

Sliders (those that are “sliders”)

Many JavaScript libraries have built-in widgets of various kinds that can be used in web applications. They work well; if javascript is enabled, of course. But it would be great if users don’t have to load a script file every time we want to add some special controls to our form.

A classic example is the slider. Until now, it was impossible to create it without the help of JavaScript. Now, with HTML5, it exists as a native Browser input with type = "range" .

 <label for="amount"> ?</label> <input id="amount" name="amount" type="range"> 

This is what input type in Safari and Opera looks like.

By default, the range of this field is from zero to one hundred. The minimum and maximum values ​​can be set using the parameters min and max, respectively.

 <label for="rating"> </label> <input id="rating" name="rating" type="range" min="1" max="5"> 

This all works well in Safari and Opera - other browsers will display just a text field. This is not so bad, and we know that if you wish, you can always add an alternative implementation of this control via JavaScript, using the check function that I already mentioned above.

Naturally, scripting solutions will take more time to load and will be less accessible for additional processing by other means than native DOM elements. However, for unknown reasons, the same range in Safari at the moment can not be friends with the keyboard ... I hope they fix it soon.

Counter

The field with the range type does not display the exact value selected by the user, but only visually represents the relative number on the slider. For some cases this is appropriate, in others accuracy is important - the ability to enter a specific value. For this, there is type = "number" .

 <label for="amount"> ?</label> <input id="amount" name="amount" type="number" min="5" max="20"> 

Browsers add “plus-minus” buttons to this field, making it a kind of hybrid between the text and range types.

date and time

One of the most popular JavaScript widgets is a pop-up calendar that allows you to select the desired date. As on most sites for booking flights, for example.

You can replace that on different sites these calendars are implemented slightly differently, so it would be nice to have one solution for the browser that eliminates this inconsistency and the need to research the nuances of a different interface in each case.

In HTML5, a handful of different types of fields are available for entering dates and times:

date - for year, month and day.
datetime - year, month, day, plus hours, minutes, seconds, and an indication of the time zone.
datetime-local is the same, but without specifying the time zone.
time - hours, minutes, seconds.
month - year and month (no number).

All these types will record the length of time in ISO format YYYY-MM-DDThh: mm: ss.Z, where Y is the year, M is the month, D is the number, h is the hour, m is the minute, s is the second and Z is the time zone . As an example - the date and time of the end of the First World War, 11 hours 11 minutes in the morning, November 11, 1918:

date : 1918-11-11
datetime : 1918-11-11T11: 11: 00 + 01
datetime-local : 1918-11-11T11: 11: 00
time : 11:11:00
month : 1918-11

There is no simple year type, but there is a week - a number from 1 to 53 combined with a year.

Using all this is quite simple:

 <label for="dtstart">Start date</label> <input id="dtstart" name="dtstart" type="date"> 

Opera copes with the implementation of the capabilities of these new fields, but they look in it not to say that it is very attractive ...

As usual, browsers that do not support this technology will display a simple text field. In this case, you can either specify in the instructions for users, in what format they should enter the date, or insert a widget for the script calendar. Again, do not forget to check its built-in support first:

 if (!inputSupportsType('date')) { //    . } 

Even the most beautifully written calendar of this kind in JavaScript will require a fairly large amount of code to generate a table of days and handle events of their choice. Built-in support for this feature should work faster and more reliably, not to mention the fact that it will eliminate the inconsistency in design.

Pipette

Perhaps one of the most daring substitutes for widgets presented in HTML5 is the field type color . It takes the values ​​as color codes in hexadecimal format: # 000000 for black, #FFFFFF for white, and so on.

 <label for="bgcolor"> </label> <input id="bgcolor" name="bgcolor" type="color"> 

The idea is to finally add built-in "pipettes" to browsers, like those found in almost all other applications on your computer. So far, it is not supported by any browser, but if it comes to this, it will be very cool.

So in this case, while you should use JavaScript-solutions, but do not forget to still check the built-in support - so as not to miss the moment when the time will come.

Do it yourself

All of these new input types serve two purposes: they allow browsers to have specially designed or customized fields for certain types of data, and know how to check the validity of this data. The HTML5 innovations described cover most of the common situations, but at some point you may very well need to create a validated input field that follows its particular principles.

The good news is that this can be implemented using the pattern parameter, where you can indicate which kind of data you are requesting. The bad news is that you have to use regular expressions.

 <label for="zip">  </label> <input id="zip" name="zip" pattern="[\d]{5}(-[\d]{4})"> 

Most of the time, the pattern parameter is unlikely to be needed. If you decide to use it - I sympathize with you.

A look into the future

The introduction of new types of web forms gives HTML5 a noticeable push forward. They shift a significant part of the burden, usually placed on JavaScript, on the shoulders of HTML5. At the moment, we are still in a transitional stage - not all of the innovations are supported by browsers, and we cannot get rid of JavaScript at all here. But the bright future is clearly not far off, we see its first rays and we can soak in them.

Validation of forms on the client side will now become much easier - although, of course, it is still impossible to fully rely on it; do not forget to check the data on the server side. Plus, for many “non-standard” data entry methods, there will now be “native” solutions that do not require users to download additional script libraries.

I’m sure you see all the advantages of calendars and sliders embedded in browsers, but I see in your eyes the logical question “Can I apply CSS styles to them?”

Unfortunately, at the moment the answer is rather - “no”. The CSS Working Group is working on this.

This may discourage you from using them at all. If specific implementations of new features in browsers do not look attractive to you, you can continue to use script widgets instead.

But I want you to ask yourself the question “Do we need to apply our styles to them?” Many of us don’t like it when unfortunate developers or designers obsessively force us to give up our habits and explore the interfaces they invented, which their opinion is better than standard (which is not always a fact). Why encourage this vicious practice of misleading users?

Personally, I would like to see browser competition for the most convenient and beautiful solutions for HTML5 web forms. I would be happy to support such a browser war.

Okay, it's done with the forms. In the next part, we will take on the new, appetizing semantics of HTML5.