HTML5 brought web development into a new era. Unfortunately, many designers haven’t really caught on to its full potential, and actually are developing HTML4 pages with a simplified doctype and header section. Looking at the source code, unless it is written by somebody who never worked in HTML4 or XHTML, you would often easily mistake it for HTML4 because those designers aren’t changing their style.
This is a tremendous shame because HTML5 really does give us some fantastic improvements over HTML4. If we really push those improvements to their limit, the results would more than justify the small investment of time required to learn how to do that.
In this article, we’ll go over some of the biggest improvements HTML5 has to offer (and which, in general, are being ignored by designers and developers), with some information on how you can put them to work for your advantage.
Big improvements for better work flow in HTML5
The big changes that came with HTML5 aren’t universally known, so here are the highlights:
1. HTML5 doesn’t need to identify itself
Just when we’d all gotten used to the need for declaring a doctype, it turns out that HTML5 doesn’t really need one at all. Yes, that’s right, not even that <!DOCTYPE html> declaration that all the books and tutorial websites tell you to have. However, just because you don’t need it doesn’t mean you shouldn’t have it. This declaration is still useful because it tells you what the document is not.
2. HTML5 gets rid of all the pesky pendantic details
It seemed once the intention of W3C was to make each new markup evolution more strict, more pedantic, and more complicated. So you can imagine the collective gasps of astonishment when it was revealed that HTML5 is less complicated than any previous implementation of markup, and we now can get more done because its so relaxed about rule enforcement. The focus of HTML5 is on productivity, not pedantic details.
3. HTML5 drops the need for identifying content types
You know the kind of code code that says something like type=”text/css”? Now you don’t have to do that. It never made sense that this was necessary, because it could be known from the file extension and the file content itself what type it was, without that needing to be declared.
Some things that are maybe not so good
It may come down to a matter of personal opinion, but there are some features of HTML5 that won’t win every heart. They include:
1. Editable content
Somebody, somewhere, thought it would be a good idea to let users edit something right there on the page. This doesn’t seem to have much practical application for anything. In fact, it could be downright dangerous, because the user could make it look like your site is saying something that it’s not. Why? For a prank.
“Hey, mom, look at what this terrible website is saying about old people!”. Then they can take a screenshot, complete with your actual URL visible in the URL bar, forward it to relevant authorities, and before you can say “legal injunction” you have a problem on your hands.
2. Unterminated tag pairs
Some HTML tags are made to stand alone (not a good feature, because consistency is a good thing), but most have required closing in order to be valid. In HTML5, that’s not the case. You don’t have to close your tags. This will potentially lead to the creation of code that’s even more difficult to read and maintain than the already-too-complex source code that properly set out HTML produces. This just doesn’t look like a great idea.
3. An annoying new incorrectly used buzz-word: semantics
A pet peeve for anyone who actually cares about semantics is the hijacking of the word “semantic”. This word actually means “something pertaining to language and the use of words”. The way it is being used in the industry, however, pertains to document structure.
Therefore it is semantically incorrect to refer to these structural elements as semantic, yet we’re stuck with this buzz-word because it is now so widely used. Professionals who are aware of this anomaly usually refer to the same elements as “structural elements”, so they won’t sound like morons. This, however, doesn’t work, because those who have adapted to the buzzword will correct you and say “Hey, it’s a semantic element. What are you, some kind of moron?”
The best bits
HTML5 gives unprecedented support for multimedia, and eliminates the need for using third party plug-ins such as Flash. Using the new multimedia features is also much simpler than the older methods, and supports more media formats.
Including video content in your page could not be more simple. You simply use a video tag pair to declare a player object and set the source for the video using an unpaired source tag. Example:
The only confusing thing there is why it’s necessary to follow the source keyword with src when they mean exactly the same thing. Although webm format is more efficient than mp4 in terms of file size, currently mp4 works in all major browsers that support HTML5, while webm may not work in older versions of IE and Safari. Therefore mp4 is the recommended format.
As you may have already guessed, adding an audio player to your page is virtually the same process, except that you declare an audio player instead of a video player. Example:
The mp3 format is supported by all browsers that support HTML5 and it is therefore the recommended audio format to use for web audio.
3. Drawing and animation
There are a few different ways to implement drawing into a web page, and some are better than the built-in HTML5 methods, but those built-in methods are there for you to exploit. There’s a steeper learning curve involved here than for the other media items, but learning these techniques will open up a lot of interesting design possibilities for you.
The primary method for drawing uses the canvas:
The above example just creates a simple primitive drawing, but you can create drawings and animations that are much more spectacular. In fact, the only limit is your own imagination.
Bitmapped graphics are so yesterday when it comes to illustrations. Until recently, SVG wasn’t widely supported by browsers, but now all major browsers that support HTML5 can display SVG content, so there’s no reason not to use it.
There is a big learning curve involved in drawing an SVG image in code, but you don’t actually need to do it that way. There are two methods you can use.
The first is to declare the SVG image the same way you would declare any other image, for example:
The disadvantage with the above method is that it may not give you access to every node as something you can manipulate with script, so the other way you can do it is to draw your image in your favorite vector drawing application (for example, Inkscape or Adobe Illustrator) and ensure you save the result as a plain SVG, which will strip out any extra information that isn’t needed.
Then open the SVG file in a text editor and copy all the markup. Paste that into your HTML document. The code will look something like this:
Typing all that out by hand would be a nightmare, but using a dedicated SVG drawing application makes it easy, and because the path ID for each node is created for you automatically, you can easily take control with scripting. Setting an ID for the SVG object itself would be a good idea, too. Then you can apply CSS styling to it.
HTML5 makes forms easier to manage
There are a few little tricks that HTML5 introduces that significantly reduce our workload when it comes to forms.
1. Enforcement of required fields
You no longer need to use scripts to check whether required fields have been filled. So many people still are doing this the old way that it was worth mentioning. To use this feature you only need to add the required to any input element. Example:
When the required keyword is present in a form field, the form can not be submitted until the field is completed. The required keyword does not check the validity of the data, only that it exists. When used in combination with other HTML5 form validation methods, it does a great job.
2. Pattern-matching for data validation
The pattern attribute lets you perform simple data validation using regular expressions. Used alone, it will only check that entered data is valid, but won’t check if it is missing. In order to force data entry and then validate it, you’ll need to use required in combination with pattern. Example:
The above example checks for a valid Canadian zip code, which resembles a string similar to the following:
It will always have this pattern of letter-number-letter-space-number-letter-number, and the first letter cannot be D,I,O,Q,U,W or Z. If you’re not already familiar with regular expressions, you’ll first need to learn about them before you can write expressions to solve problems like the one in the example, and then you’ll need to learn how to adapt ordinary regular expressions to work as HTML5 patterns.
A special type of input control that has built-in pattern validation is the email type. Using this, you don’t need to define a pattern. Example:
These are things you can both love and hate at the same time. It’s true placeholders can cause confusion for some users, but they also can be really helpful if you don’t have a lot of screen space available for your form components. Placeholders put ghost text into an input area, which can be used either as a replacement for a label or to provide an input example. They’re especially useful on mobile layouts. Example:
The big problem with placeholders, especially when they’re used as example input, is that they can lead to UX complications. The first such confusion is that users might consider the placeholder text as being physically present in the input area, and thus they may try to manually delete or modify it by positioning the cursor at an appropriate point, which of course won’t work.
A related problem is where your sample input exactly matches the input the user wanted to type. They may consider the data to already be filled, and not type anything in manually. When submitted, the form processor will treat the field as empty, not as containing the placeholder text, and it will produce the wrong result.
Making sure your form sends focus to the correct input area can be important, and you do this with the autofocus keyword, used in the same way as required. Example:
Adding autofocus to more than one component may cause your carefully planned form to malfunction.
Document structure – a matter of semantics
As mentioned earlier, the use of the word “semantics” is wrong for structural elements, but that argument is in itself simply a matter of semantics. So choose what name you will, the function of them is still the same – to help you better understand your document structure when reading it.
Most developers are still using div for this job and that’s fine. Using the structural elements just makes everything a touch more official, and it’s easier to read the source code. There’s no real advantage to using structural elements in your document. For the sake of completeness, we’ll briefly step through them.
An article is some part of the page that is isolated in context from everything else on the page. It’s a complete portion of content that doesn’t relate to other portions of content. Using this element doesn’t solve any problems for you.
Similar to articles, but without the intention of defining that the content isn’t related to any other content. So for example, you may have an article that is divided into sections, and a section could contain one or more articles. These are purely for your own reference, to help you organize the source code, however you also get features identical to using a real div.
This is supposed to contain things like titles, logos, and other things like that.
A dedicated section for navigational components.
Defines content that’s supposed to be treated like a sidebar (though there’s no rule about where an aside gets placed, its actual placement is up to you).
The first—and perhaps only—structural element that serves any kind of purpose at all is the figure element. Using these makes you sound all academic, and what spoiled upper-class English girls of the Victorian era would have described as “frightfully clever”.
Figures let you encapsulate images so you can include captions with them. Example:
The correct use for a footer is to contain footnotes, but it’s more usually used to provide miscellaneous links, copyright information, and contact information. You can put anything inside it that you want.
There’s a lot more to discover, but the above methods from HTML5 have reached a point of maturity now where they shouldn’t be getting as ignored as they are. Many sites, for example, continue to use the antiquated and soon-to-be-obsolete Flash Player to provide video content, which is just plain crazy.
Making the jump from HTML4 to HTML5 isn’t difficult at all, but dropping those HTML4 habits may be a lot harder, and that’s probably why HTML5 hasn’t been embraced as fully or as enthusiastically as expected.
Using HTML5 properly, without including unnecessary HTML4 artifacts will make development faster. It will make your code more readable and easier to maintain. And it will ensure your pages aren’t weighed down with legacy code you don’t need.