HTML5 - Eric Feminella

HTML5 Structural Elements

The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation.
– Tim Berners-Lee

The HTML5 Specification introduces many new semantic elements intended to provide meaning to the structure of a document. These elements are quite important as they allow for marking up a document in meaningful ways which, prior to HTML5, would have otherwise required a rather ambiguous markup consisting primarily of divs, ids, and classes to provide some semblance of semantic structure.

Being purely markup based, it is understandable why these new semantic elements may not excite as much interest as many of the more attention grabbing HTML5 specifications, such as audio, video, Web Workers, WebSockets, Web Storage etc. However, it is important, perhaps even necessary, to emphasize the significance these new elements present in terms of helping to solidify the realization of what the web is intended to be: an open medium for disseminating homogeneous and heterogeneous information.

With this in mind, combined with an informed understanding of the context in which each new semantic element can be applied, overtime the Web will, quite naturally so, evolve in many new, exciting, and perhaps previously unthought-of ways.

Broadly, the new Structural elements introduced in HTML5 can be succinctly summarized as follows:

The <header> Element

The <header> element is rather self explanatory in that it allows for defining content which is to be denoted as a header of a page, or a header within a section of a page. Headers typically provide introductory and / or navigational content via hgroup and nav elements. What is important to keep in mind is that multiple <header> elements can be defined per page.

<h2>Some Blog Description</h2>

<p>Last Modified: <time>2011-10-19</time></p>

</header>

W3C Specification (section 4.4.8)

The <nav> Element

The <nav> element represents an important section of navigational links to specific pages or specific sections within the current page. As such, not all navigational links need be defined within a <nav>.

<h2>Some Blog Description</h2>

<p>Last Modified: <time>2011-10-19</time></p>

<nav>

<h1>Navigation</h1>

<ul>

<li><a href="about.php">About</a></li>

<li><a href="contact.php">Contact</a></li>

</ul>

</nav>

</header>

W3C Specification (section 4.4.3)

The <article> Element

The <article> element provides a means by which content can be represented independently from the document or application with which it is associated. General examples could include, as one may have guessed, an article from a newspaper, a blog post, a comment on a blog post, a self contained UI widget, and so forth.

</header>

<p>This is a simple example of the article element.</p>

</article>

W3C Specification (section 4.4.4)

The <section> Element

The <section> element defines generic sections of a document, article or entire application. The section element is intended to provide semantics for a document and is not intended to be used as a container for styling purposes, in which case a <div> element should be used.

</header>

<p>This is a simple example of the article element.</p>

<h1>Comments</h1>

<p>Posted by: Eric Feminella</p>

</header>

<p>Nice post, simple enough!</p>

</article>

</section>

<h1>Categories</h1>

</section>

</article>

W3C Specification (section 4.4.2)

The <aside> Element

The <aside> element represents content which is relevant to, or supportive of it’s surrounding content, but is not required to convey the information set forth by the surrounding content. General examples could include a pull quote, a blog roll, a sidebar etc.

</header>

<p>This is a simple example of the article element.</p>

<h1>Comments</h1>

<p>Posted by: Eric Feminella</p>

</header>

<p>Nice post, simple enough!</p>

</article>

</section>

<aside>

<h1>Categories</h1>

</aside>

<aside>

<li><a href="semantics/">semantics</a></li>

<li><a href="elements/">elements</a></li>

</ul>

</aside>

</article>

W3C Specification (section 4.4.5)

The <footer> Element

As with the <header> element, the <footer> element is rather self explanatory in that it allows for defining content which is to be denoted as a footer of a page, or a footer within a section element for it’s nearest ancestor. A page can contain multiple <footer> elements, each unique to a particular section.

</header>

<p>This is a simple example of the article element.</p>

<h1>Comments</h1>

<p>Posted by: Eric Feminella</p>

</header>

<p>Nice post, simple enough!</p>

</article>

</section>

<aside>

<h1>Categories</h1>

</aside>

<aside>

<li><a href="semantics/">semantics</a></li>

<li><a href="elements/">elements</a></li>

</ul>

</aside>

</footer>

</article>

W3C Specification (section 4.4.9)

Putting it all Together

The following example is comprised of each semantic element described above to form a complete, valid HTML5 document:

<!doctype html>

<html>

<head>

<title>HTML5 Semantic Structure Example</title>

</head>

<body>

<h2>Some Blog Description</h2>

<p>Last Modified: <time>2011-10-02</time></p>

<nav>

<h1>Navigation</h1>

<ul>

<li><a href="about.php">About</a></li>

<li><a href="contact.php">Contact</a></li>

</ul>

</nav>

</header>

</header>

<p>This is a simple example of the article element.</p>

<h1>Comments</h1>

<p>Posted by: Eric Feminella</p>

</header>

<p>Nice post, simple enough!</p>

</article>

</section>

<aside>

<h1>Categories</h1>

</aside>

<aside>

<li><a href="semantics/">semantics</a></li>

<li><a href="elements/">elements</a></li>

</ul>

</aside>

</footer>

</article>

</body>

</html>

October 19, 2011 HTML5 / UX Design

2 Comments

Interconnectivity in JavaScript with Peerbind

The ability to facilitate interconnectivity between multiple clients has always presented some rather interesting possibilities for both simple and complex Web Applications alike. More often than not, such interconnected applications would require complex server-side configurations (often proprietary in nature) in addition to numerous infrastructure considerations.

Peerbind, a new JavaScript API, remedies many of these complications by providing a very simple client-side API built on jQuery.

Peerbind is quite unique in that it provides an event binding API (on top of jQuery) that is shared amongst all connected clients of the same interest. Essentially this allows for binding something as common as a “click” event (or any event for that matter, including custom events) such that each active instance of the same application across the web will be notified of the event. As one might imagine, this allows for some rather compelling possibilities.

To demonstrate just how quickly and easily interconnectivity can be plugged into a web application using Peerbind (and the Peerbind public server), below is a simple example which displays a new item each time a new “peer” views the example page since loaded (hint: try opening a few instances, either in tabs or separate browsers).

<!doctype html>

<html>

<head>

<title>Simple Peerbind Example</title>

var Peers = (function() {

var added = function(e) {

var timestamp = new Date(e.timeStamp);

var visitor = e.srcPeer ? "New Visitor" : "You";

var item = "<li>" + visitor + " arrived on " +

timestamp + "</li>";

$("#visitors").preppend(item);

}

var init = function() {

var body = $(document.body);

body.peerbind("peer", added);

body.peertrigger("peer");

}

return {

init: init

}

}());

$(document).ready(Peers.init);

</script>

</head>

<body>

</body>

</html>

Example (run)

Simple enough!

Of course, for most applications there are obvious security concerns which would need to be addressed as well as issues of scale and availability to take into consideration. That being said, if you haven’t checked out Peerbind yet and would like to quickly and easily add interconnectivity to your application or leverage it’s simplicity to prototype such features, it is certainly worth taking for a test drive.

Comments Off

Test Driven Javascript with QUnit

For the past year I have been using jQuery Mobile for developing web based mobile applications leveraging HTML5, CSS3 and JavaScript. Like all UI implementations, meaningful test coverage is essential to ensuring requirements have been met and refactoring can be achieved with confidence. Building applications for the Mobile Web is no different in this respect. And so, a high quality Unit Testing framework is as essential to the success of Mobile Web Applications as it is to their Desktop counterparts.

Why QUnit?

While there are quite a few good JavaScript Unit Testing Frameworks available, Jasmine in particular, I have found QUnit to best suit my particular needs for implementing Test Driven Development in JavaScript based on it’s clean design and practical implementation.

A Simple, Powerful API

The power of QUnit lies in it’s simple and a rather unique approach to Test Driven Development in JavaScript. The QUnit API introduces a few slightly different test implementation concepts when compared to the more traditional xUnit style of TDD. In doing so, QUnit succeeds in simplifying some of the tedium of writing tests by leveraging the language features of JavaScript as opposed to strictly adhering to the more traditional xUnit conventions, the design of which is based on an fundamentally different language idiom – that is, Java.

For example, consider the follow which tests for a custom data namespace attribute in jQuery Mobile:

test("Test expected namespace override", function() {

var expected = "someNamespace-";

var actual = $.mobile.ns;

equal(actual, expected, "expecting namespace to have been set.");

});

Figure 1 (run) (source)

The above test may appear quite straightforward, yet it serves as a good example by illustrating how each test in QUnit is implemented by the QUnit test fixture. The first argument is simply a String which describes the test case. This is quite convenient in that the intent of a particular test case can be expressed more naturally in textual form as opposed to using a long, descriptive test method name. The Second argument contains the actual test implementation itself, which is defined as an anonymous function and passed as an argument to QUnit.test.

As you may have also noticed from the above example, there are some, perhaps subtle, differences between the QUnit style of testing and the traditional xUnit style. Specifically, whereas in xUnit assertions expected values are specified first and preceded by actuals, in QUnit actuals are specified first followed by expected values. This may feel a bit odd at first however, after a few tests it’s easy to get used to. Additionally, where an assertion message is specified before any arguments in xUnit, in QUnit assertion messages are specified after all arguments. With regard to test descriptions, this is a difference I prefer as, a test message is always optional so passing this value last make sense. While somewhat subtle differences, these are worth noting.

A Complete Example

As code can typically convey much more information than any lengthy article could ever hope to achieve, I have provided a simple, yet complete, example which demonstrates a basic qUnit test implementation. (run) (source).

September 19, 2011 CSS3 / HTML5 / JavaScript / Refactoring / Software Engineering / TDD / BDD / UX Design

1 Comment

Tracking HTML5 Support in Chrome

Google has now made it easy to track the current implementation status of HTML5 in Chrome via The Chromium Projects’ new Web Platform Status page.

Many of the sections have links to their html5rocks site, which provide further details and more in-depth tutorials of implemented specifications.

The current sections include:

This is certainly something to keep an eye on as, Chrome is setting the standard in terms of HTML5 support by desktop browser vendors.

September 18, 2011 APIs / Browsers / CSS3 / HTML5 / JavaScript

Comments Off

HTML5 Elements: The <base> Tag

The HTML5 Specification introduces many new semantic elements, as well as specifications for existing elements; one of which is the <base> Tag, which allows for specifying a root URL from which all linkable elements in a document (hyperlinks, images etc.) are based, as well as a default target for all linkable elements.

Overview

The <base> Tag provides two attributes; href (Hyper-text Reference) and target, respectively, which have the same semantic meaning as that of a hyperlink.
Only a single <base> Tag is to be defined per page and, must be defined before any elements which except a URL are defined (other than the html element).

Note: While the <base> Tag is not new to HTML5, the changes to the a Tag implies a difference (albeit, marginal) as, a Tags are always hyperlinks, or placeholders for hyperlinks.

Example

Like all HTML markup, usage of the <base> Tag is easy and straightforward: Simply add a single <base> Tag in the <head> element of the document and define either a base URL and / or default target attribute.

Defining a default base URL and target:

<!DOCTYPE html>

<html>

<head>

</head>

<body>

<nav>

<a href="aboutus.php">About Us</a>

<a href="contactus.php">Contact Us</a>

</nav>

</body>

</html>

The above links will all default to a blank target (new page), with each link’s base URL defaulting to “http://somedomain/app”. Individual links can override the base URL as well as the default target.

Support

The <base> Tag is currently supported by all major browsers.

September 1, 2011 HTML5

Comments Off

HTML5 Semantics: The contenteditable Attribute

The HTML5 Specification introduces many new semantic attributes in addition to new semantic elements. One particularly interesting addition is the introduction of the contenteditiable attribute, which can be found under the User Interaction Specification in Section 7.5.

A Brief Overview

The contenteditiable attribute allows for the editing of content within any valid HTML5 element. By default, elements implicitly inherit edibility from their parent element unless explicitly defined.

The API

The contenteditiable attribute is an enumerated attribute with three states which map to the four keywords:

true
The `true` state indicates that the element is editable; it is specified by the (`"" Empty String`) or `true` keywords.
false
The `false` state indicates that the element is editable; it is specified by the `false` keyword.
inherit
The `inherit` state indicates that the element is editable if it’s immediate parent element is editable.

Examples

The following examples provide basic “live” demonstrations and source implementations of the contenteditiable attribute. (Note: These examples assume an HTML5 compatible Browser which support this attribute.)

A basic editable element

This content is editable, try it.

<p contenteditable="true">This content is editable!</p>

A basic nested editable and non-editable element

By default, this content is editable via it’s inherited parent elements value.
This content is not editable via it’s explicit contenteditable value.

<li>By default, this content is editable via its

inherited parent elements value.</li>

<li contenteditable="false">This content is <b>not</b>

editable via its explicit contenteditable value.</li>

</ul>

Outline Styles

Setting editable element outline styles with CSS attribute selectors:

[contenteditable=true] {

outline: 1px dotted #cccccc;

}

[contenteditable=true]:hover {

outline: 1px dotted #ff0000;

}

Complete example

<!doctype html>

<html>

<head>

<title>HTML5 Semantics: The contenteditable Attribute</title>

<style>

[contenteditable=true] {

outline: 1px dotted #cccccc;

}

[contenteditable=true]:hover {

outline: 1px dotted #ff0000;

}

</style>

</head>

<body>

<p contenteditable="true">This content is editable!</p>

<li>By default, this content is editable via its

inherited parent elements value.</li>

<li contenteditable="false">This content is <b>not</b>

editable via its explicit contenteditable value.</li>

</ul>

</body>

</html>

run

Some Concluding Thoughts

As you can see, enabling and disabling an editable element in HTML5 is quite simple with the addition of the contenteditiable attribute. This allows for some very interesting possibilities when implemented in conjunction with many of the other new features in HTML5; specifically, the Web Storage API and the spellcheck attribute.

April 15, 2011 HTML5

3 Comments