HTML5 » Eric Feminella

CSS3 Attribute Selectors

The power of CSS Selectors can not be understated; for, without them, there would be no simple means by which developers could target specific elements for styling in a manner abstracted from, or external to, the actual markup to which the styles will bind.

In addition to some of the more common Simple Selectors, such as Type Selectors, Class Selectors and Id Selectors, we have have Attribute Selectors, which, as the name implies, allow us to match elements based on their attributes.

Attribute Presence and Value Selectors

CSS2 introduced four Attribute Selectors; referred to as Attribute Presence and Value Selectors, which allow for course grained matching of specific elements based on their attributes and / or attribute values. These include the following:

e[attr]

Where e is an element and [attr] is an attribute of element e. For example, p[title] would match all p tags with a title, regardless of the value of the title.

/* Matches all <p> tags with a title and changes their background color 
   to red with white text */
p[title]{
    background-color: red;
    color: white;
}

/* Matches all <p> tags with a title and changes their background color

to red with white text */

p[title]{

background-color: red;

color: white;

}

e[attr=val]

Where e is an element and [attr=val] represent an attribute of element e which contains the exact value of val. For example, p[title="Example 1"] would match all p tags with a title which equals “Example 1″ exactly.

/* Matches all <p> tags with a title equal to "Example 1" and changes
   their background color to green and text color to white */
p[title="Example 1"]{
    background-color: green;
    color: white;
}

/* Matches all <p> tags with a title equal to "Example 1" and changes

their background color to green and text color to white */

p[title="Example 1"]{

background-color: green;

color: white;

}

e[attr~=val]

Where e is an element and [attr~=val] is an attribute of element e which has a value containing a whitespace-separated list of words, one of which equals val exactly. For example, p[title~="Example-1a"] would match all p tags with a title containing the word “Example-1a” in a list of whitespace delimited words.

/* Matches all <p> tags with a title containing the exact word to "Example-1a" 
   and changes their background color to black and text color to red */
p[title~="Example-1a"]{
    background-color: black;
    color: red;
}

/* Matches all <p> tags with a title containing the exact word to "Example-1a"

and changes their background color to black and text color to red */

p[title~="Example-1a"]{

background-color: black;

color: red;

}

e[attr|=val]

Where e is an element and [attr|=val] is an attribute of element e that has a value of val exactly, or begins with val immediately followed by a hyphen “-”. For example, p[title!="Example"] would match all p tags with a title containing the word “Example-”, followed by any other value, such as “Example-1″, “Example-A”, etc..

/* Matches all <p> tags with a title containing the word to "Example-" and 
   changes their background color to blue and text color to white */
p[title|="Example"]{
    background-color: blue;
    color: white;
}

/* Matches all <p> tags with a title containing the word to "Example-" and

changes their background color to blue and text color to white */

p[title|="Example"]{

background-color: blue;

color: white;

}

View Example

Substring Matching Attribute Selectors

In addition to the above Attribute Presence and Value Selectors, CSS3 expands on this by defining three additional Attribute Selectors; referred to as Substring Matching Attribute Selectors. These additions allow for fine grained matching of specific elements based on their attribute values.

In simplest terms, the new Attribute Selectors in CSS3 can be used to match an element with a given attribute whose value begins, ends or contains a certain value. The following is a basic description and example of each new Attribute Selector:

e[attr^=val]

Where e is an element and [attr^=val] is an attribute of element e which contains a value that begins with val.

/* Matches all linked resources sent over https */
a[href^="https"]{
    color: red;
}

/* Matches all linked resources sent over https */

a[href^="https"]{

color: red;

}

e[attr$=val]

Where e is an element and [attr$=val] represent an attribute of element e which contains a value that ends with val.

/* Matches all anchor tags to .html documents */
a[href$=".html"]{
    color: green;
}

/* Matches all anchor tags to .html documents */

a[href$=".html"]{

color: green;

}

e[attr*=val]

Where e is an element and [attr*=val] is an attribute of element e which has a value that contains val.

/* Matches all anchor tags which contain a query string */
a[href*="?"]{
    color: blue;
}

/* Matches all anchor tags which contain a query string */

a[href*="?"]{

color: blue;

}

View Example

To summarize, there are a total of seven Attribute Selectors in CSS3, three of which are new. Whether used for general matches, such as global Attributes; e.g. *[hreflang|=en] or more specific matches, such as chaining; e.g, a[href^="https"][target="_blank"], Attribute Selectors provide a powerful mechanism for selecting both general and specific content within a page.

No comments

CSS3 selection pseudo-element (dropped)

With both the CSS3 Selectors and CSS3 Namespaces Modules, respectively, having been released as official W3C recommendations (Selectors, Namespaces), I felt compelled to re-review each specification.

Interestingly, while reviewing the CSS3 Selectors Module (my personal favorite), I noticed that the selection pseudo-element selector which was originally drafted for CSS3 had been dropped from the proposal. In fact, it was dropped a rather long time ago.

In case you are not familiar with the selection pseudo-element, essentially it allows for defining the text color and background-color of selected text within a document.

For example, all <code> elements on my site have a red background with white text when selected – such as this text here (select it) – based on the following two simple rules:

// IE, Chrome, Safari, Opera
code::selection { background: #ca3131; color:#fff; }
code::-moz-selection { background: #ca3131; color:#fff; }

// IE, Chrome, Safari, Opera

code::selection { background: #ca3131; color:#fff; }

code::-moz-selection { background: #ca3131; color:#fff; }

And so, while having been dropped, support is already rather good (FF3.6, SA3.1+, OP9.5+, CH2+, IE9) and as far as I am aware Browser vendors will continue to support ::selection.

November 2, 2011 CSS3 / HTML5

1 comment

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 and ids to provide 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) evolve in many new, exciting and perhaps previously unthought-of ways.

Broadly, the new semantic 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.

<header>
    <h1>Some Blog</h1>
    <h2>Some Blog Description</h2>
    <p>Last Modified: <time>2011-10-19</time></p>
</header>

<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>.

<header>
    <h1>Some Blog</h1>
    <h2>Some Blog Description</h2>
    <p>Last Modified: <time>2011-10-19</time></p>
    <nav>
        <h1>Navigation</h1>
        <ul>
            <li><a href="home.php">Home</a></li>
            <li><a href="about.php">About</a></li>
            <li><a href="contact.php">Contact</a></li>
        </ul>
    </nav>
</header>

<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.

<article>
    <header>
        <h1>Some Post</h1>
        <p><time pubdate>2011-10-02</time></p>
    </header>
    <p>This is a simple example of the article element.</p>
    <p>...</p>
</article>

</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.

<article>
    <header>
        <h1>Some Post</h1>
        <p><time pubdate>2011-10-02</time></p>
    </header>
    <p>This is a simple example of the article element.</p>
    <p>...</p>
    <section>
        <h1>Comments</h1>
        <article>
            <header>
                <p>Posted by: Eric Feminella</p>
                <p><time>2011-10-1</time></p>
            </header>
            <p>Nice post, simple enough!</p>
        </article>
    </section>
    <section>
        <h1>Categories</h1>
        <span><a href="/html5">HTML5</a></span>
    </section>
</article>

</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.

<article>
    <header>
        <h1>Some Post</h1>
        <p><time pubdate>2011-10-02</time></p>
    </header>
    <p>This is a simple example of the article element.</p>
    <p>...</p>
    <section>
        <h1>Comments</h1>
        <article>
            <header>
                <p>Posted by: Eric Feminella</p>
                <p><time>2011-10-1</time></p>
            </header>
            <p>Nice post, simple enough!</p>
        </article>
    </section>
    <aside>
       <h1>Categories</h1>
       <span><a href="/html5">HTML5</a></span>
    </aside>
    <aside>
       <ul id="tags">
          <li><a href="semantics/">semantics</a></li>
          <li><a href="elements/">elements</a></li>
          <li>...</li>
       </ul>
    </aside>
</article>

</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.

<article>
    <header>
        <h1>Some Post</h1>
        <p><time pubdate>2011-10-02</time></p>
    </header>
    <p>This is a simple example of the article element.</p>
    <p>...</p>
    <section>
        <h1>Comments</h1>
        <article>
            <header>
                <p>Posted by: Eric Feminella</p>
                <p><time>2011-10-1</time></p>
            </header>
            <p>Nice post, simple enough!</p>
        </article>
    </section>
    <aside>
       <h1>Categories</h1>
       <span><a href="/html5">HTML5</a></span>
    </aside>
    <aside>
       <ul id="tags">
          <li><a href="semantics/">semantics</a></li>
          <li><a href="elements/">elements</a></li>
          <li>...</li>
       </ul>
    </aside>
    <footer>
        <div class="g-plusone" data-annotation="inline"></div>
    </footer>
</article>

</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>
        <meta charset="utf-8" />
        <title>HTML5 Semantic Structure Example</title>
    </head>
    <body>
        <header>
            <h1>Some Blog</h1>
            <h2>Some Blog Description</h2>
            <p>Last Modified: <time>2011-10-02</time></p>
            <nav>
                <h1>Navigation</h1>
                <ul>
                    <li><a href="home.php">Home</a></li>
                    <li><a href="about.php">About</a></li>
                    <li><a href="contact.php">Contact</a></li>
                </ul>
            </nav>
        </header>
        <article>
            <header>
                <h1>Some Post</h1>
                <p><time pubdate>2011-10-02</time></p>
            </header>
            <p>This is a simple example of the article element.</p>
            <p>â€¦</p>
            <section>
                <h1>Comments</h1>
                <article>
                    <header>
                        <p>Posted by: Eric Feminella</p>
                        <p><time>2011-10-13</time></p>
                    </header>
                    <p>Nice post, simple enough!</p>
                </article>
            </section>
            <aside>
                <h1>Categories</h1>
                <span><a href="/html5">HTML5</a></span>
            </aside>
            <aside>
                <ul id="tags">
                    <li><a href="semantics/">semantics</a></li>
                    <li><a href="elements/">elements</a></li>
                    <li>...</li>
                </ul>
            </aside>
            <footer>
                <div class="g-plusone" data-annotation="inline"></div>
            </footer>
        </article>
    </body>
</html>

<!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 / User Experience Design

No 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>
     <meta charset="utf-8" />
     <title>Simple Peerbind Example</title>
     <script src="http://code.jquery.com/jquery-1.4.4.js"></script>
     <script src="http://js.peerbind.com/jQuery.peerbind.js"></script>
        <script>
            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>
        <ul id="visitors"></ul>
    </body>
</html>

<!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.

October 6, 2011 Browsers / HTML5 / JavaScript / jQuery

No comments

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.");
});

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 Agile / AJAX / CSS3 / HTML5 / iPad / iPhone / JavaScript / jQuery / jQuery Mobile / Mobile / Mobile Web / Refactoring / Software Engineering / Tablets / Test Driven Development / User Experience 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

No comments

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>
    <base href="http://somedomain/app" target="_blank" />
</head>
<body>
    <nav>
        <a href="index.php" >Home</a>
        <a href="aboutus.php">About Us</a>
        <a href="contactus.php">Contact Us</a>
    </nav>
</body>
</html>

<!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 / Mobile Web

No comments

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>

<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.

<ul contenteditable="true">
    <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>

<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;
}

[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>
        <meta charset="utf-8">
        <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>
        <ul contenteditable="true">
            <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>

<!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

Multiple Form Factor Software Design

I have been giving a lot of thought lately about designing software in a Multi-Form Factor paradigm and felt I would share some initial thoughts on the subject. Keep in mind much of this is still quite new and subject to change; however, I have made an attempt to isolate what I feel will remain constant moving forward.

First, User Experience Design

My initial thoughts on the implications of what an ever growing Multi-Form Factor paradigm will have on the way we think about the design of software are primarily concerned with User Experience Design. While using CSS3 media queries to facilitate dynamic layouts will be needed for most Web Applications, I do not believe these types of solutions alone will allow for the kinds of compelling experiences users have come to expect, especially as they will likely compare Mobile Web Application experiences to their native counterparts. Sure some basic solutions will be needed, and for some simple websites they may suffice. However, in the context Web Applications, as well as just about every application developed specifically for a PC, too, I believe UX Design will need to leverage the unique opportunities presented by each particular form factor, be it a PC, smartphone, tablet or TV. Likewise, UX will need to account for the constraints of each form-factor as well. Architecturally, all of the above presents both opportunity and challenge.

To further illustrate this point, consider the fact that it is arguably quite rare that a UX Design intended for users of a PC will easily translate directly to a Mobile or Tablet User Experience. The interactions of a traditional physical keyboard and mouse do not always equate to those of soft keys, virtual keyboards and touch gesture interactions. Moreover, the navigation and transitions between different views and even certain concepts and metaphors are completely different. In simplest terms; it’s not “Apples to Apples”, as the expression goes.

With this in mind, as always, UX Design will need to remain at the forefront of Software Design.

Second, Architecture

Multi-Form Factor design obviously poses some new Architectural challenges considering the growing number of form factors which will need to be taken into account. The good news is, most existing, well designed software architectures may have been designed with this in mind to a certain degree. That is, the key factor in managing this complexity I believe will be code reuse; specifically, generalization and abstraction. A common theme amongst many of my posts, code reuse has many obvious benefits, and in the context of Multi-Form Factor concerns it will allow for different device specific applications to leverage general, well defined and well tested APIs. A good example being a well designed RESTful JSON service.

Code reuse will certainly be of tremendous value when considering the complexities encountered with Multi-Form Factor design. Such shared libraries, APIs and Services can be reused across applications which are designed for particular Form-Factors or extended to provide screen / device specific implementations.

Some Concluding Thoughts

In short, I believe both users and developers alike will be best served by providing unique User Experiences for specific Form Factors as opposed to attempting to adapt the same application across Multiple Form Factors. One of the easiest ways of managing this complexity will inevitably be code reuse.

I also believe the main point of focus should be on the medium and small form factors; i.e. Tablets and Smart phones. Not only for the more common reasons but, also because I believe PCs and Laptops will eventually be used almost exclusively for developing the applications which run on the other form factors. In fact, I can say this from my own experiences already.

While there is still much to learn in the area of Multi-Form Factor Design, I feel the ideas I’ve expressed here will remain relevant. Over the course of the coming months I plan to dedicate much of my time towards further exploration of this topic and will certainly continue to share my findings.

March 6, 2011 Agile / AJAX / Android / APIs / Browsers / Code Review / CSS3 / Design Patterns / HTML5 / iPad / iPhone / JavaScript / jQuery Mobile / Mobile / Mobile Web / Object Oriented Design / Refactoring / Software Engineering / Tablets / Test Driven Development / User Experience Design

No comments

Web Timing Specification

The Web Timing Specification (draft) aims at providing a standard set of APIs which allow for true end-to-end instrumentation of page load times across browsers.

To quote the w3 spec: “This specification (Web Timing Specification) defines an interface for web applications to access timing information related to navigation and elements.” The API is based on the Navigation Timing and Resource Timing interfaces, respectively.

While I haven’t seen this specification mentioned as part of the HTML5 Family before, in many ways I would consider it to be a worthy candidate for membership as it provides a standards based API through which web applications can be tested for load efficiency. This is obviously something quite useful for any web application as, the ability to precisely measure page load times – and implement optimizations as needed – affords developers the opportunity to provide an improved user experience.

Historically, the ability to accurately measure page load times of web applications has been quite challenging for a number reasons. Just knowing when and where to begin is debatable and, determining the best means of doing so can be a challenge in of itself. Regardless of any current strategies being used, the result is never entirely accurate. With Web Timing developers need not be concerned with these specifics as the API provides the ability to truly measure page load times by encompassing the full scope of loading and parsing a page. This includes the time involved to request, receive and render an HTML document.

For more information, try out the examples in the current supported browsers; IE9, Chrome 6.

July 20, 2010 AJAX / Android / APIs / HTML5 / iPad / iPhone / JavaScript / Mobile

Comments Off