HTML5 Web Development

Published on 14 Oct 2012 at 5:41 pm.
Filed under Informative,rant.

The HTML5 logo.

HTML5 is fuel that will power the next generation of web applications. It has changed the face of web development. But what about the present?

How HTML5 Was Formed

It was the year 2004. The World Wide Web Consortium (W3C) focused on creating a totally new markup language for the web known as XHTML 2.0. It had very little backwards compatibility with XHTML 1.0, which was just an XML representation of HTML 4.01. The W3C was pushing the web to become more semantic. It viewed every web page as a document. These documents needed to have content separated from presentation and behavior. Content would be the text, pictures and videos that you see on a page. Presentation would be definitions that say that the text is black on a white background. Behavior would be changes to the document based on certain actions. For example, a form that hides or shows fields based upon your answer to a question.

But they went too far. Take the example the simple task of opening a link in a new window. Under XHTML 1.0 Strict definition this was illegal behavior. Sure, no browser cared and they still actually opened it in a new window. But the W3C would rather have you use JavaScript (preferably an external file) to run once the page loaded to look up that specific link and set an onclick handler that then tells the browser to open the link in a new window. Many lines of code that could only be created by a developer just to replace adding the attribute target="_blank" to your link. This would be something any WYSIWYG editor could easily automate for you. This was easy to understand. This had been valid, simple, and widely deployed. This is the type of mentality you would expect from academia, not private entities such as Apple, Microsoft, Adobe, Opera, HP, and AT&T.

Enter the Web Hypertext Application Technology Working Group (WHATWG). The WHATWG was originally composed of people from Mozilla, Apple, and Opera. They wanted the web to be more than it was. They wanted to simplify common tasks and have access to build better tools. Above all they didn’t want to scrap anything that already existed in HTML 4. They created a specification called Web Applications 1.0. This specification would later be retitled HTML5 and would be adopted by the W3C who would work with the WHATWG (they had the time since everyone gave up on XHTML 2). The specification would again be retitled simply HTML because they believed that they were never going to stop making changes and saw little need in minor numbers. The WHATWG has created other specifications such as Web Workers, Microdata, and Web Forms 2.0. While technically different specifications, these specifications, as well as CSS3, are commonly lumped together when people are talking about HTML5.

What Does HTML5 Do?

HTML5 defines new elements such as header, footer, nav, section. They may look merely semantic, but they have practical applications. Links inside of a nav element are likely to be common navigational elements on your site. Search engines appreciate that. Marking up content into sections allows screen readers the ability to easily present this information to users.

HTML5 also defined audio and video elements. The Web Development community was really tired of requiring users to download browser plugins like Flash just to play a video or a song. That is clunky. It’s a barrier to entry that shouldn’t exist in today’s world. We don’t need to download plugins to display a picture. Unfortunately, patents got in the way. This caused a political war between web browser companies over what file formats they would support. Ultimately you will need to encode your audio and video files into multiple formats in order for everyone to use them. But hey, the user won’t need to have any plugins installed ….

Web forms have been dramatically overhauled in HTML5. HTML5 introduces new input types that allow browsers to perform validation routines prior to form submission. It also allows mobile devices to toggle the native input based off of the type of the field. For example, the email input type could have an ‘@’ as one of the keys, while the telephone input type would display a phone’s dial keypad. New input types include:

• Email.
• URL.
• Number.
• Telephone
• Search
• Color
• Date
• Time
• Date and time.
• Week.
• Month.

Unfortunately, many of these fields are only partly supported at this time. Some browsers support the native validation of an input type, but do not bring up the native controls for them. Even more unfortunate, most of those native user interface controls do not yet allow a web designer to change the style of the control. But browsers are rapidly improving their HTML5 support.

There are also new attributes that go along with the input types. File uploads can now support multiple files being selected at once. You can mark a field as required to prevent the user from being able to submit the form until they have filled out a value. Placeholders can display a bit of text until the user clicks on that field. Pattern attributes could be left to confirm that an input matched a certain criteria. Datalists allow you to supply values that can be auto-completed as soon as a user begins to input text. This lets the user input whatever they wanted but gives them a hint at what you would like them to input. This is esthetically superior to having a drop down in your field with a value of “Other” and then having another box that they can type what they want.

You could do most of those things using JavaScript before. You will still need it to build in support for browsers that do not yet support these input types or attributes. It is refreshing to see things going in the right direction. The HTML5 specification authors recognized that web developers were going to want to support their own custom validation routines. For example, you could use JavaScript to confirm that two password fields matched, or do an ajax lookup to confirm that the zip code entered was valid for a given state.

CSS3 is often lumped in with HTML5. CSS3 brings with it animation capabilities, as well as transitions and 2D and 3D transforms. This means that you can use CSS to rotate the images on a page by 30 degrees. Rather than just hiding or showing an element at the click of a button you can animate the element as it shrinks or grows. CSS3 tried to bring native gradients to web browsers. By having native support you could use JavaScript to change a color value arbitrarily. Unfortunately, the spec writers had trouble getting this right. In order to define a gradient that goes from red (#FF0000) at the top to blue (#0000FF) at the bottom you would need to define the element like so:

background-image: -webkit-gradient(linear, left top, left bottom, from(#FF0000), to(#0000FF));
background-image: -moz-linear-gradient(top, #FF0000, #0000FF);
background-image: -webkit-linear-gradient(top, #FF0000, #0000FF);
background-image: -o-linear-gradient(top, #FF0000, #0000FF);
background-image: -ms-linear-gradient(top, #FF0000, #0000FF);
background-image: linear-gradient(to bottom, #FF0000, #0000FF);

Notice something funky about that? They started out with one syntax and saw that it was cumbersome. Mozilla implemented their own version which was well received. It was then copied in WebKit (Chrome and Safari), then Opera, and then Microsoft in their platform previews for Internet Explorer 10. Then someone noticed that you couldn’t create a gradient on an angle. This resulted in a new syntax after it had achieved universal support with a prefix. This is fine, but Mozilla suddenly dropping their vendor prefixed syntax and adopting the unprefixed version in the same release did NOT make endear to this web developer’s heart.

This blog post was originally published as HTML Web Development for The BrandBuilder Company.