Ethan Poole

When did HTML 5 become HTML5?

Ethan Poole — Fri, 20 Aug 2010 07:30:00 -0500

I am still bitter about the W3C’s decision to discontinue the development of the XHTML 2 standard in favour of devoting more resources to HTML 5. I do however understand that it made sense, from a resource perspective, to allocate the organisation’s energy towards a specification that was already slowly gaining adoption, rather than towards the “pipe dream” that was XHTML 2. Nevertheless, a year after the decision was made, I have an increased disdain for HTML 5, except no longer solely because of its poorly devised solutions and subsequent killing of any hopes of a real semantic Web, but because “HTML5” has morphed into a conglomerate blanket term for the “future Web”.

“HTML5” was initially known as “HTML 5”, the character “5” meaning the fifth version of HTML. Despite popular understanding, HTML 5 was developed outside of the W3C by Ian Hickson and the Web Hypertext Application Technology Working Group (WHATWG) in response to the W3C’s decision to focus on XHTML. It was loosely brought back into the W3C’s fold after a lengthy period of organisation politics (Ian Hickson is the editor for both the W3C’s and the WHATWG’s HTML specifications). At the time, the next versions of HTML and XHTML were known as HTML 5 and XHTML 2 respectively. Whilst HTML 5 had gained little headway in browser adoption, it was leaps ahead of XHTML 2. Browser vendors apparently were not enthusiastic about XHTML 2’s “let’s start over” approach.

On 2 July 2009, the world of (X)HTML changed when the W3C officially announced the discontinuation of the XHTML 2 Working Group, making HTML 5 the de facto winner. Some people were happy. Some people were not.

Somewhere in this transition, “HTML 5” became “HTML5” (without the space). Whilst you may consider this minor linguistic change to be insignificant, I argue that it epitomises the concurrent shift in the meaning of the term “HTML 5”/“HTML5”. In July 2009, HTML 5 referred to the HTML 5 Working Draft, which established a backwards compatible approach to improve HTML, introducing a handful of useful new tags, detailing precisely how HTML, both valid and invalid, should behave, and increasing the semanticity of HTML in general. HTML 5 was made by and for web developers. Flash forwards to the present day and HTML 5 has morphed into an abstract and meaningless blanket term for HTML 5 (the specification), CSS 3, <canvas>, geolocation, local storage, web sockets, and far too much more. HTML 5 has fallen to the marketing wolves, the exact culprits who coined “Web 2.0” and — God forbid — “social media”.

Apple and Google are each responsible in part for HTML 5’s change in meaning. They continually claim that their browsers have the most “HTML5” support, plastering it as a “feature” in their marketing material. Naturally, they actually mean Safari and Chrome have good support for a number of emerging web technologies, one of which is HTML 5, but I digress. Since Apple and Google have pretty big voices in the technology industry, their blanket meaning for “HTML5” has caught on with the media. I am sorry, but a website cannot have “HTML5” features or look “HTML5-ish”. Marketers and the media may have gotten away with using the coined term “Web 2.0” in such contexts, but can we please not let them hijack HTML 5 too?

Whilst I do primarily blame Apple and Google for hijacking the term HTML 5, I also question the role of the WHATWG in the shift of meaning. Did they secretly always intend for HTML 5 to become this behemoth? I am at least sceptical of the W3C splinter group, so I decided to investigate the situation. First, I catalogued the deletion of the space in the official W3C HTML 5 specification:

2010-06-24: HTML5
2010-03-04: HTML5
2009-08-25: HTML 5
2009-04-23: HTML 5
2009-02-12: HTML 5
2008-06-10: HTML 5
2008-01-22: HTML 5

The first official specification draft, published on 22 January 2008, was titled “HTML 5”. The term “HTML 5” subsequently persisted for four more published draft iterations, until the term “HTML5” officially replaced “HTML 5” in the working draft published on 4 March 2010.

As a casual observation, the switch from “HTML 5” to “HTML5” appears to have happened right around the time when the “HTML5” hype started to proliferate. However, after some research, I uncovered a blog post on the WHATWG blog from 10 September 2009 that directly addresses the “spelling” dilemma. They claim the group had always internally referred to HTML 5 as “HTML5” and everyone else should spell it as such. The next official published draft also rectified the “error”.

The problem is that every existing W3C specification uses a consistent naming scheme, in which a space separates the technology’s name and the version number. What gives HTML 5 the right to break this convention? Has the W3C lost so much power that it cannot retain even its naming convention?

Whilst I appreciate the push for HTML 5 since it is rapidly improving the Web, I still feel uneasy about how the process is taking place. First, HTML 5 was developed outside of the W3C and consequently has severely weakened the W3C’s authority in shaping the future of the Web. Second, HTML 5 has become a weapon in the corporate arsenals of Apple and Google, allowing them to claim support for “open standards” and to push HTML 5 in the direction of their corporate roadmaps (i.e. the <video> tag).

Removing the space from “HTML 5” is like using “r” in place of “er” in Web 2.0-style names: it is something marketers do, not something web developers do. Even though we developers gain undoubtably more capabilities from HTML 5’s adoption, the push for HTML 5 is no longer about us, it is about marketing. HTML 5 is merely a feature. As I stated earlier, the shift from “HTML 5” to “HTML5” epitomises the shift in meaning, but it also epitomises the shift in ownership.

Why I moved to Django from PHP

Ethan Poole — Mon, 16 Aug 2010 07:24:31 -0500

Whilst developing the redesign of this website, I reached the conclusion that something was fundamentally wrong in my coding workflow, which was seriously impacting my productivity and my ability to move projects into production. In the past two years, I have outputted a pitifully meagre amount of work, attributable on one hand to having considerably less free time, but also attributable to my obsession with coding everything myself from scratch. Despite working with PHP, which has a plethora of third-party code, I rarely utilise anything third-party and, hence, I spend a lot of time reinventing the wheel. I had to ask myself: what is wrong with third-party PHP code? I came up with the following core reasons:

No adherence to any syntactical conventions, resulting in a mismatched feeling.
Poor or non-existent documentation.
Indiscernible, lazily constructed code.

I simply have a problem placing ugly, poorly written code into my projects; it bothers me. However, I knew that I needed to adopt a coding framework at the very least to save my productivity, and perhaps my sanity, so I resolved to investigate a few frameworks thoroughly. My initial conclusions were notably dismal:

Zend Framework: Too much work even for relatively simple tasks.
CakePHP: Far too restricting.
CodeIgniter: Lacklustre OOP (due to PHP4 support).
Ruby on Rails: Extremely appealing for all of about five minutes, until I recalled the general my-shit-smells-like-roses attitude of the Rails community.

Then it hit me, why not try Django and Python? After one week of tinkering and experimenting with Django, I was convinced and at the point of no return. Some of the aspects that initially impressed me were:

Don’t Repeat Yourself (DRY). Quite often I get pretty OCD about duplicate code, so it is enormously refreshing that Django adheres so religiously to the DRY principle.
Admin scaffolding. Most of my personal projects, unless for a freelance client, lack an administrative interface because it is by far the most boring thing to code. Django automatically builds an administrative interface based on one’s project’s models, whilst still allowing a high level of customisation, unlike competing scaffolding solutions in PHP.
Easy, yet scalable models. I have always loved Zend Framework’s models because they are solidly programmed and remarkably scalable; however, they simply are time consuming to configure. Django’s models take a different approach, but are both easy and scalable.
Powerful templating language. Generally, I would loathe the idea of a dedicated templating language, but Django’s templating language’s more limited scope and template inheritance does a remarkable job of forcing display logic and application logic to be separate.
Decoupled and modular code. A Django project is composed of multiple “apps”, each of which is designed to perform a specific set of related functions, such as a blog or a contact form. Initially, this setup may appear restricting, since applications undoubtably will have to communicate with one another on some level, but Django does facilitate communication between applications via “signals”. Applications dispatch and respond to signals, a level of interaction amongst applications that does not require their codebases to intermingle. The result: remarkably modular code.

After having spent so many years in the PHP sphere, dealing with absolutely terrible code and novices smiling happily at their poorly structured applications, Python was immensely refreshing. Python enforces some basic code-readibility standards at the language-level, such as tabs and clearly-defined namespaces. Furthermore, in areas of potential untidiness, such as naming conventions, Python programmers quite religiously follow PEP-8 (Style Guide for Python Code). Granted, whilst I do not think that there is anything intrinsically wrong with PHP, I do not see a discernible path for PHP to improve its over-forgiving syntax. There will always be more bad PHP programmers than skilled PHP programmers. Moreover, PHP 5.3’s implementation of namespaces — which introduces a bizarre syntax that fails to conform to any of PHP’s preexisting syntactical conventions — destroyed any of my remaining hopes that PHP’s syntax could improve someday.

Now that I have reprogrammed this website using Django, I have a much more clear-cut understanding of Django’s appeal to me personally. Most relatively good frameworks are far too restricting, à la Ruby on Rails and CakePHP, or are far too cumbersome, à la Zend Framework. Django straddles between these two extremities, undertaking all of the mundane aspects of developing a website, whilst maintaining a level of coding freedom simply by not getting in one’s way.

My other initial thoughts about and experiences with Django will eventually manifest into blog posts of their own, but my overall initial impression is that Python is PHP without the suck and that Django is just the right amount of framework.

Länge leve brudparet!

Ethan Poole — Mon, 21 Jun 2010 04:16:00 -0500

Last Saturday marks an important day in Swedish history, the marriage of Crown Princess Victoria of Sweden to Daniel Westling. As tradition dictates, the marriage was held in Storkyrkan (The Great Church) in Stockholm, followed by a reception in Stockholms slott (Stockholm Palace). Numerous royal dignitaries from around the world attended and the entire event was broadcasted on television. Victoria and Daniel are now peacefully residing in Haga slott (Haga Palace).

Crown Princess Victoria and Daniel Westling at their wedding. [1]

The royal wedding was monumental because Victoria is the first heiress apparent to marry and Daniel Westling is the first male commoner to become a member of the Swedish Royal Family since the Middle Ages. Since 1980, the Swedish monarchy has practised absolute cognatic primogeniture, in which the first-born inherits the throne regardless of gender. Victoria will be one of Sweden’s few queens regnant, the fourth to be precise, and therefore the royal protocol in this situation is far less established than it would be for a crown prince.

Furthermore, many people were upset with Victoria marrying a commoner; Daniel Westling was the Crown Princess’ personal trainer. However, numerous Swedish princes and kings have married women outside of royal stock, including the current King Carl XVI Gustaf. Queen Silvia originally worked as an interpreter before she met the King at the 1972 Summer Olympics in Munich. Needless to say, there is no reason a princess should not be able to marry a commoner if a prince or king can.

The Swedish Royal Court bestowed Daniel Westling with the title Hans Kunglig Höghet Prins Daniel av Sverige, Hertig av Västergötland (His Royal Highness Prince Daniel of Sweden, Duke of Västergötland).

Here are a few news articles summarising the wedding:

Den långa bröllopsdagen i kortformat (Dagens Nyheter)
Historiskt när Daniel säger ja (Aftonbladet)
A wedding fit for a princess (CNN)

Personally, as the monarch is meant to represent the people, I see no problem with Victoria’s marriage. We all ideally want to marry for love, so why should our representative have to do otherwise? Most Swedes I know have no problem with whom Victoria married, merely that the tax payers picked up the bill for the immaculate wedding. That, however, is a topic for another day!

I only wish Victoria and Daniel a happy life together. Länge leve brudparet!

And so begins a new era

Ethan Poole — Sat, 19 Jun 2010 18:27:00 -0500

Last summer, during a fit of abnormal amounts of free time sans classes, I decided to start a new blog. My old blog was filled with poorly written, terribly articulated posts and contained far too many ABBA references. Starting afresh seemed like the most viable option. The project quickly grew in scope, becoming a project to establish a unified online presence for myself: a single website to house both my portfolio and my blog. Fast forwards to about one month ago, I realised that after countless iterations and designs, I had made seemingly no progress. Bummer. I did however have a finalised design, or at least a sense of one, and I decided to work towards something “releasable” instead of the beautifully polished product I had initially envisioned.

The website you are currently viewing is the end product of all this work. Everything should function properly, but I will be making numerous incremental improvements over the coming weeks. Even with work remaining, it feels amazing to have my website finally online!

For those who are interested, you can read more about me, browse through my portfolio, or contact me. I also invite you to follow me on Twitter at @ethanp or to subscribe to my blog via RSS. Last, I realise that “welcome” entries, albeit necessary, are absurdly boring and self-centred. Bear with me because I intend to post a “real” blog entry tomorrow when my eyes have had a rest from the three-hour coding marathon I have just endured!

Ha det bra och välkommen åter!