Oct 14 2009

Using HTML as a Service end-point... sort of...

If you polled 10 of your nerdiest friends the majority would probably say that HTML is a presentation language and is not suitable for application-to-application communications.  If you asked the same 10 about XML, they would probably unanimously agree XML is suitable.  If you annoy them one last time and ask 'why not HTML', they will probably point to the rules regarding closing tags, case sensitivity, etc... In other words, strictness.

Ok, true...  XHTML fills some of that need, there are also HTML DOM solutions, and if developers weren't so lazy and they would just code in a stricter manner Wink. Lets just assume the laws of nature prevent us from considering changes in behaviour as a solution. Lets also assume we need something that forces us to structure our HTML more like XML. Well here comes HTML 5, which appears to be trying to fill the gap between the two. Visit a draft HTML 5 site and you may see something like this:


<!doctype html><html><body></body></html>

or even this:


<?xml version="1.0" encoding="UTF-8"?><html xmlns="http://www.w3.org/1999/xhtml"><body></body></html>

I will not review the details of the draft standard, for that you need to visit http://www.w3.org. Note the doctype in the first example, Essentially the standards community has heard our many complaints about HTML strictness/conformance and called our bluff.  Once you read the spec you start to realize choices related to common complaints are... well... choices.  They have allowed us to define and follow very strict patterns or follow very loose patterns like old HTML. What will be fun to see is how many of us actually start becomming stricter.  Lets face it, from a presentation perspective this will not make much difference.

While they still give us rope to hang ourselves they are really leaning everyone towards a pattern of application-to-application communications, whether they are browsers, sync devices like phone, e-book readers, Outlook, Services, or whatever. Review the spec and you will see a lot of new tags for a wide range of very specialized purposes going way beyond rendering content for a users web browser. So what now? Let get back to the real issue...  Us! Go on... noone is looking... you can acknowledge your guilt.

No matter what standard you conform to, you should think of some of your HTML content as a Service. I mean it just makes sense.

  • There are tons of applications and devices that can; or should be able to; parse select content for things like contacts, appointments/schedules, news, product details, license info, geospatial/map data, social media, etc.  In this case, these are applications that are not browsers, but are an extension of services that we can provide our users.
  • For our own sake, testing applications can have an easier time of assessing aspects of your applications behaviour if they can see data as data and not as presentation content.

Lets dig in to the latter bullet point.  The abbreviation pattern is lightweight, simple, and doesn't add much to your markup but provides data in both human and machine readable formats:

Date/Times:


<abbr title="2008-04-10T06:30:00.0000000-07:00">Your apointment on April 10th 2008</abbr>

IETF Language Codes:


<abbr title="es-419">Spanish as used in Latin America</abbr>

Currencies:


<abbr title="EUR"></abbr>

Phone Numbers: (Note: This is great example of app-to-app integration. If you have Skype installed you will probably see additional options to call this phone number. This costs you nothing but enhances experiences for users that use these types of tools.)


<abbr title="+18885555050">1 (888) 555-5050</abbr>

Abbreviations:


<abbr title="AKA">Also Known As (A.K.A.)</abbr>

Ok, I will not beat a dead horse, but really...  Can't we all just get a bit stricter?

But wait! There's still more! If you are still not sure what I am saying is true, consider the following structural elements added in HTML 5:

<header>
<section>
<title>
<nav>
<article>
<aside>
<footer>

Among other things, these elements can all be accomplished using the tried and true <div> tag. So why add these, they really do little for presentation? The authors of the HTML 5 spec set these and other's aside specifically to support integration between applications. For example, with broad agreement on their meaning content within these elements can easily be identified and parsed/ignored. As an example, accessibility applications like screen readers can target your main content (e.g. <article>) and ignore the rest until needed.

There are a lot more examples of these patterns in the HTML 5 spec, so I encourage you to give it a look. Enjoy...

Tags: