AIAIO: Our Blog

Everyone is jumping on the HTML5 bandwagon, and we at Ai are no exception! For a while I’ve been a little reluctant to introduce the new revision for our projects mainly due to the lack of solutions that would target cross-browser compatibility out of the box. As an ecommerce shop, browser compatibility means more users, means more revenue, means happy client.

For the past couple years I’ve been monitoring the development of HTML5 Boilerplate, a project created by Paul Irish and Divya Manian, aimed to seamlessly integrate HTML5 and modern CSS3 features into your site across all browsers (even back to IE6). The current 1.0 build was recently released with a bunch of goodies such as HTML and JS minification, image compression, cache management, updated CSS reset, custom build script, the option to choose modernizr or html5shiv, and so much more.

To learn more about the project visit html5boilerplate.com.

While HTML5 has a nice amount of new tags for semantic markup as well as media-based tags such as <video>, <audio>, or the JavaScript-based <canvas> tag, there are a handful of other new elements that are still worthy of mention:

• <command> is used to define a button, such as a radio button, or check box. It must be used inside of a <menu> element.
• <article> is used to define an article from an external source – news site, blog, forum, etc.
• <datalist> defines a list of options, such as a drop-down menu. This tag is used in conjunction with the <input> tag.
• <dialog> is used to define a dialog or conversation.
• <embed> defines external content or plugins. This element has been used in previous HTML versions but is now re-introduced as an HTML5 standard.
• <figure> is used to represent flow content, separate from the primary content of a document. Additionally, the <figcaption> element is used within <figure> in place of the older <legend> element.
• <meter> is used to define a scalar measurement within a known range. For example, think of this as a representation of a “2 out of 10″ score.
• <time> represents time on a 24-hour clock, or a date in the proleptic Gregorian calendar.
• <source> is used in conjunction with the new media elements, <audio> and <video>, to define multiple source files.
• <ruby> defines a ruby annotation – Chinese notes or characters. <rt> is a child of <ruby> and is used to define the explanation of the ruby annotation. <rp> is used for browsers that do not support ruby annotations.
• <mark> represents a run of text in a document that has been marked or highlighted due to its relevance in another context. This new element is similar to the existing <strong> and <em> elements, though it is only used in terms of relevance and not importance or emphasis.
• <progress> defines the completion amount of a task. This could be used to display the download progress of an object.
• <keygen> represents a key pair generator control. When the control’s form is submitted, the private key is stored in the local keystore, and the public key is packaged and sent to the server.
• <output> defines the result of a calculation, such as output written from a script.
• <details> is used to show details about a document, or parts of a document. A user can obtain information or controls from this element. <summary> is a child element to show the summary/control of the <details> element. Think of this as an expanding area where the summary is a cickable link to “See more information.”
• <hgroup> is used to group a section of headings (<h1> – <h6>) when there are multiple levels of headings (primary heading, subhead, tagline).

The HTML5 standards draft is not 100% finalized as of the publish date of this post but is close to completion. The current draft of the proposed new standards can be viewed at http://dev.w3.org/html5/spec/Overview.html.

HTML5 will be a great thing, once supported enough across the spectrum of browsers. Until then, only some of the new elements can be utilized in common practice. Internet Explorer will certainly not understand how to render CSS on a majority of the new elements, but there is a means to force IE to read and accept the elements by means of JavaScript so CSS styles can be applied.

Something as simple as document.createElement(‘section’); will tell IE to render the <section> tag. While this method has been tested, and does work for a majority of the new HTML5 elements, there is still the issue of accessibility. Given that JavaScript must be used for IE to render the elements, it cannot be relied upon as a common practice in HTML development. If a user does not have JavaScript enabled on their browser, it will completely break a web page using this method. It is therefore safe to say that we will not see most of the new HTML5 tags used in general development until we at least see the death of Internet Explorer 6 and possibly IE7 and IE8.

A new element introduced in HTML 5 is the <canvas> tag which can be used to draw graphics by means of a scripting language such as JavaScript. In the markup, it acts very similar to the HTML <img> tag, but there is no need for src or alt attributes – only width and height can be used, but both are optional. With no values given, the area will default to 300px wide and 150px high. Below is a simple example of what the markup would look:

<canvas id=”draw” width=”500″ height=”300″>
<p>Your browser does not support the canvas element.</p>
</canvas>

While <canvas> does not require a closing tag in Safari, it is required in Firefox and is best practice to always use one so the element will render properly in all supportive browsers. The <p> is used for alternative content when a user’s browser does not support <canvas> – an <img> can be used here as well. Alternative content could not be utilized if a closing tag is not used. An id attribute is used in the code sample in order to identify the element in the JavaScript.

Like all other HTML elements, <canvas> can be styled with CSS (margin, border, etc.) but those styles will not be applied to the actual content within the <canvas>. In the example below, a dotted border is used to display the actual <canvas> element:

Your browser does not support the canvas element.

When viewed in a supportive browser, two rectangles should be seen above – One green, one opaque blue. This example is quite simple and just a mere demonstration of the ability to draw with JavaScript.

One of the nice features of the <canvas> element is text replacement, generally tackled by sIFR (Flash-based text replacement). Cufón is a text replacement method which utilizes the <canvas> as a means to display copy with the specific font of choice. One major drawback to the Cufón method is the amount of HTML code generated, making a simple heading element bloated enough to make a developer cringe. While it is better than sIFR, with the need for a third-party (Flash) plugin to be installed, it is still not a perfect means for text replacement.

Accessibility with the <canvas> element is a concern for many developers. There are no current native methods to generate markup from the content produced within the <canvas>. Using alternative content can be helpful but it must be manually input by the developer, and it will not be true to what the element’s actual content is displaying.

The methods used to create <canvas> content is rather pain-staking, considering the end result. Drawing with JavaScript creates many lines of code, and the end result does not seem worth it. Some great examples of what people are cooking up with this new element are located at www.canvasdemos.com. There are definitely some cool effects that can be used to make a website more lively, but in terms of practical use I don’t foresee a heavy use of this new element. It seems to be more application-driven for a specific purpose (see: Tiny Doodle), which most websites will have little to no use for. Once <canvas> becomes more widely-used and supported it is likely that scripting libraries, similar to MooTools, will be built. This would enable developers to create <canvas> content with much more ease.

The semantic web is an ever-evolving development to define the meaning of content viewed on the web. It is the responsibility of an HTML developer to build web pages with a sharp understanding of how the front-end markup should be structured. With the upcoming release of HTML5, new tags will be introduced to the language that will enable more fluid communication between the web and the people and machines that use it.

The common practice of laying out HTML markup these days is the use of the <div> tag, using id or class attributes to block out content. New tags included in HTML5 will display a much more readable layout when defining areas of a web page. Some of the important tags in this group are <section>, <aside>, <header>, <footer>, and <nav>. It is likely that most of these tags clearly state what they are doing, but each still deserves it’s own explanation:

• <section>

  This tag will be used to define generic content within a document. While id and class attributes will still be needed, this will still lay out a cleaner mode of blocking content than the now-standard <div> tag, thought the latter tag will not be deprecated and can still be used.

• <aside>

  Sidebar content will be separated using this tag to show content that is “to the side” of main content areas. Generally this content is partially related to the primary focus of a given web page.

• <header> and <footer>

  The topmost and bottommost blocks of content are often referred to as the “header” and “footer.” Naturally, HTML5 introduces tags that clearly define this. It is likely that id and class attributes will no longer be needed with the use of the tags, unless a developer opts to use the <header> tag inside of a <section> tag.

• <nav>

  Navigation menus will have their own tag in the markup, however it is uncommon for modern websites to have less than three nav menus on a single page, so id and class attributes would still be needed.

Below is a screenshot of how this code might look. The new tags form a much more readable structure to the markup of the page. It creates a much cleaner view and gives the viewer a better of understanding of what is being displayed.

View a live example (it may not be the prettiest site, but it’s more for the markup than anything)

One of the most beautiful aspects of the above examples is the HTML Document Type Declaration, or DOCTYPE. It is the absolute first statement in every single web page, and is used to trigger standards mode in a browser and then determines what iteration of the language is in use. In earlier versions, there was specific data required as part of the declaration, which may look something like this:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

Earlier versions of HTML were based on SGML, Standard Generalized Markup Language, but HTML5 is not and therefore has no need for the extra junk in the DTD. Here is the new one:

<!DOCTYPE html>

As previously stated – beautiful.

There are a few other new tags that are still worthy of mention: <article> to block content for blog entries or news articles, <dialog> used for marking up a conversation, and <figure> to be used when associating a caption with embedded content (audio or video).

It is debatable whether these new standards should be used, considering that full cross-browser support for HTML5 is not there yet. Firefox, Safari, Chrome, Opera, and a few smaller browsers will support most of these new tags, but older versions of Internet Explorer will not. Allegedly, there is a way to use JavaScript to force Internet Explorer to acknowledge that the new tags exist, but if a user has JavaScript disabled in their browser, the page will not render properly. Given that IE6 and IE7 still have a large-enough share on the browser market, this hack method does not seem sound enough to use in common markup yet.

The direction the semantic web is going will no doubt enhance the overall user experience of the web, even if the user is not consciously aware of it. This markup overhaul will create a better environment to display content and has the potential to make web pages even just slightly faster and more scalable. These are all good things.

As an Ai Fender (front-end developer), I live in a world of HTML markup. The next revision of this language is HTML5, though it is currently not fully supported across all browsers. Some of the core ideas behind HTML5 are to create more semantic markup based on usage of modern browsers, and to say farewell to the necessity of proprietary plugins required to access certain types of media on the web – namely audio and video content.

For the first in my series of emerging front-end web technologies, I am going to detail the new <video> tag feature. This may not be the most important new feature of HTML5, but I am certain it will be the most widely-used by the general population of internet users. Video content on the web has evolved immensely over the last five years – YouTube, Hulu, Vimeo, and the list goes on. It would be difficult to find a person who has used the internet and never watched a single video on YouTube.

Currently, users need the Shockwave plugin to view Adobe Flash content, or the Silverlight plugin to view Microsoft Silverlight content. The <video> tag will now allow internet users to view video content without the need to download such third-party plugins to view said content. This could easily boost a site’s traffic and page views if more users can access the video content.

Below is a simple example of the <video> tag in action. Unfortunately, it will only be viewable in Mozilla Firefox, Apple Safari, or Google Chrome (more to come on those browsers after the video).

For those not using a browser capable of handling the <video> tag, I have also included screenshots of what the players in each browser look like.

Firefox Video Player

Safari Video Player

Chrome Video Player

Each browser has its own unique user interface for displaying video content. The player controls all have the basic, fundamental features one would expect: play/pause, scrub through timeline, view time, and ability to control volume. Negative points to Safari for a lack of volume level slider and only giving mute functionality. Though I am sure that all browsers are still fine-tuning their interfaces as this technology is more or less a work-in-progress.

The major drawback to this new method of displaying video content is the formatting of the files used. Safari and Chrome both require their video files to have an H.264 codec or most other Quicktime codecs (Adobe Flash also utilizes the H.264 codec for Flash Video/FLV files), where Firefox requires the OGG Vorbis codec. What this means for developers is the need for multiple video file formats included in the markup, which is actually quite simple and not time-consuming.

The real problem exists with OGG and how difficult it is to find a means to export a video file to that format. It is not impossible, but a plugin is required to use with video conversion software in order to export a video to .ogg format. Ultimately, it is now the task of the developer to install a third-party plugin needed in conjunction to this <video> tag, even though the plugin is not for a browser. But if it aids in creating a better experience for the end user, I am absolutely okay with it.

YouTube has an opt-in experimental version of their video player built using HTML5, but it will only work in browsers that support both HTML5 and H.264 codec. Give it a try: http://www.youtube.com/html5

When I find a bundle of interesting links, I send them in an email to all of Ai. I thought I would start sharing them here as well. I am always hopeful they will spark some conversation, so feel free to leave comments if you have anything to say.

• Beautiful HTML Markup – Learn some HTML standards (some of this is based on the forthcoming HTML5).
• Google Acquires AdMob for $750 Million in Stock – Google buys mobile advertising startup, AdMob (Google is gobbling everything up: Blogger, YouTube, AdMob, Picasa, On2, reCaptcha, Gizmo5, and a slew of others).
• Digital Distractions – How many of these apply to you?
• Murdoch: We’ll probably remove our sites from Google’s index – Rupert Murdoch may remove News Corporation sites from Google’s index.