Four years and two days ago, Tim Berners-Lee wrote Reinventing HTML where he infamously admitted:

"It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work."

and then went on to announce the plan to charter a completely new HTML group and a separate group to work on the XHTML2 work which the old "HTML working group" was working on. with the explicit caveat of independence: There will be no dependency of HTML work on the XHTML2 work.

Similar words were said about XForms. Both moves (accommodating XHTML2 and XForms) were largely political, doomed from the start but perhaps providing a smoother, but slower, more face-saving termination path.

Just over three years after Tim's blog post, W3C announced the end of work on XHTML2:

"...when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed."

Draconian = FAIL

What Tim failed to mention, and what was perhaps the biggest nail in the coffin for use of XML (and thus "real" XHTML) on the web, was its draconian error handling. Here's an actual example I screen-captured:

Now, I was actually quite shocked to see this, as in practice nearly nobody (maybe Sam Ruby) serves content as "actual" XML or XHTML (content-type of text/xml, application/xml, or application/xhtml+xml), and this screenshot is exactly why.

It's too easy for content to subtly break some form of XML-validity, and then have the browser provide an ugly and unfriendly warning message like the above. This happens because XML requires that browsers and anybody else that parses XML handle errors in a very draconian manner, that is, to stop processing at the first error.

Given a choice, nearly no one wants the browser to stop displaying because of an error, and thus nearly no one serves XML on the Web.

That's the real reason XML failed. Because a policy of draconian error-handling is a policy of failure.

XHTML coding practices

Getting back to Tim's points, I have no problem with including quotes around attribute values and slashes in empty tags and in fact have found that doing so, and validating as such, catches more errors sooner for me and thus I (as many web developers do) find it beneficial to code with such XML strictness.

In general the practice of coding "compatible XHTML", based on the informative Appendix C. of the XHTML 1.0 spec, has been fairly well accepted by modern web developers as a best practice.

But there are other aspects of XHTML that have no discernible benefit, for example:

• xml:lang attributes, in addition to lang attributes
• xmlns="http://www.w3.org/1999/xhtml" namespace declaration

I haven't bothered with xml:lang attributes in quite some time. However, I have sometimes (inertia?) still included the xmlns XHTML namespace declaration.

Prioritizing, minimizing, and losing some xmlns

When I started coding Falcon (the code that now runs the home page and permalinks of tantek.com), I had to prioritize, minimize, and coded only what I needed.

I used XML-valid HTML5+hAtom as the data store for Falcon. Natively viewable (HTML5), compatible with well known syndication semantics (hAtom), and easily readable/writeable on the server using built-in PHP DOMDocument interfaces.

Eventually I noticed that I had omitted the xmlns XHTML namespace declaration and apparently didn't need it. The client (browser) didn't need it. The server (Falcon/CASSIS/DOMDocument) didn't need it.

The only place I continued to use the xmlns XHTML namespace declaration was in my Atom feed, largely just quickly modeled/copied from my old Atom feed that I used to generate with HyperCard back in the day (only a few years ago, ahem).

Does xmlns stymie Google?

I use the xmlns declaration in a few places in my feed. Everywhere I have content, I wrap it in divs with the xmlns:

• <title type="xhtml"> of the Atom <feed>
• <title type="xhtml"> of each Atom <entry>
• <content type="xhtml"> of each Atom <entry>

If you look at my feed in either Safari or Firefox, you'll see the content as you might expect, with some browser-specific feed styling.

If however you view my content through Google Reader, or see it syndicated into Google Buzz, you'll see that every entry shows the feed title with visible <div> markup, having errantly overescaped the contents of the feed's <title> element., e.g.

Nevermind the display of duplicate content from the title and the contents of the entry - Google should know better (either heuristically or due to the use of the Activity Streams note object-type) - but that's a separate bug.

Google has known about the overescaping problem (failure to parse XHTML in Atom <title> elements) for over 3 months now (since July 13th 2010). They eventually added it to their public bug database last month. This seems like a small quick fix that should be trivial for the Google geniuses, and yet, no progress, no comments, and no estimate for when they might look at it.

Google is in many ways helping spearhead and accelerate the development of a Federated Social Web, with their work on PubSubHubbub (including a nice easy to use hub), and work on the Salmon notification specification. These are huge complex tasks. But equally important is rapid iteration and fixing annoying little parsing bugs like incorrect double-escaping of nested XML/XHTML.

To be clear: I'm not asking Google to handle some sort of broken markup for backward compatibility. I'm simply asking Google to parse Atom feeds properly as XML.

Losing my xmlns

I have been fairly outspoken about the failure of namespaces for content, XML namespaces in particular. I use xmlns in Atom only to avoid the even worse practice of escaping markup to embed markup inside markup (what RSS makes you do).

However, remembering four years ago, and my own loss of xmlns in my HTML5 documents, I've decided to drop xmlns from the title of my feed as well - it's not necessary today, and highly doubtful that I'm going to include markup there in the future.

Towards XML-valid HTML5

Longterm I don't believe in Atom, nor any other draconianly fragile XML format. I include Atom simply because for now, it's a part of the glue for the Federated Social Web. In the future I can see replacing it with hAtom, parsed from HTML5 documents.

However, I personally, as a developer and publisher, still see benefits from XML coding practices, not the least of which is being able to maintain HTML5+hAtom data stores (and thus avoid the even worse problem of database maintenance). So for now, I'm going to continue coding my HTML5 with quoted attributes, explicit closing tags, and self-closing empty elements, making them what I call "bi-glot" documents: both HTML5, and valid XML.

I've given up on "proper" XHTML (by any definition). Long Live XML-valid HTML5.

A couple of weeks ago the New York Times (NYT) published an article with <title> "Web Upgrade HTML 5 May Weaken Privacy" and heading: New Web Code Draws Concern Over Privacy Risks which chicken-littled HTML5 with as far as I can tell, purely theoretical concerns while never having written an article about vulnerabilities from Java which are actually used and for sale.

Evercookie: the return of Samy

The NYT article mentions an "Evercookie" proof-of-concept created using new HTML5 features by Samy Kamkar who infamously "went to Chipotle and ordered ... a burrito" after launching his MySpace "Samy is my hero" profile worm which gave him over a million friend requests. Obviously Samy has established his credibility, but nowhere is it explained (not by NYT nor Samy) how his "Evercookie" poses any kind of real threat or exploit. Vague references to "tracking" and "privacy" are made without any actual explanation.

Thus not an actual exploit (just a proof of concept), nor any documentation of actual potential harm. A prime example of chicken-littling.

Java vulnerabilities empower exploit kits

On the other hand, in his post Java: A Gift to Exploit Pack Makers, Brian Krebs lists and specifically documents (emphases mine):

• Specific commercial (for sale) "exploit kits", like "Blackhole". (i.e. actual exploit implementations)
• Effectiveness in the wild metrics: on average this kit finds a working exploit that it can use to install malicious software on a visiting host about 10 percent of the time.
• Java vulnerability ubiquity compared to others: Java vulnerabilities are by far the most useful, comprising more than 90 percent of all successful exploits.
• Multiple exploit kits' screenshots confirming Java's most vulnerable status: SEO Sploit Pack ... Java vulnerabilities are the most productive, accounting for between 50 and 65 percent of malware installs or "loads"
• Naming more specific exploit kits that primarily leverage Java vulnerabilities: Crimepack and Eleonore

Let me make this clear: these exploits allow outside attackers, to take over your machine, and then use it for whatever they want, e.g. extract your passwords and local personal data, or add your machine to a botnet (imagine Skynet but with (supposedly) a human (perhaps highest bidder) issuing the commands) for more nefarious distributed attacks on other machines.

Theoretical and abstract vs. real and concrete

Thus on the one hand you have the theoretical and abstract "tracking" danger from new HTML5 features reported by the New York Times, and on the other hand the real world concrete danger of having your machine taken over due to Java vulnerabilities.

Brian wonders why this is so in the tech press in particular:

"But for some reason, Java seems to get a pass from the tech and security press, even though Java flaws consistently are found to be the most useful for attackers who wield these automated exploit kits."

I wonder too.

New York Times, When Will You Cover Java Vulnerabilities?

Dear New York Times, are you ignorant on web security, not doing your homework, or deliberately omitting coverage of Java vulnerabilities, perhaps afraid of being sued (as Java corporations have done previously and recently) ?

Disable Java NOW

Given the real threats that Java vulnerabilities pose to your machine, and frankly, it's rarely used for anything essential, I highly recommend you disable Java in all your browsers.

Especially if you use a Macintosh, note that Apple has deprecated Java and will stop shipping it in software updates and software installs. This is especially important because if you check the official Verify Java Version page (noted by Brian Krebs in Java Update Clobbers 29 Security Flaws), you'll see a note for Mac Users:

Mac Users: Use the Software Update feature (available on the Apple menu) to check that you have the most up-to-date version of Java for your Mac.

Right, those software updates which have deprecated Java as noted. Time to bail.

How to turn off Java in browsers

Here's how you turn off Java in common browsers (these instructions are for Macintosh versions, Windows browsers are likely similar. If someone posts instructions for Windows browsers, I'll link to it.)

• Camino 2: (thanks to Eric Meyer)
  • From the Camino menu, choose Preferences...
  • Click Web Features (with globe/switch icon) in the top row
  • Uncheck [ ] Enable Java
  • Close the Preferences window (titled Web Features at this point)
• Chrome:
  • There is no direct UI in Chrome. You have to:
  • Go to about:plugins (if clicking that link doesn't work, copy/paste it into a new tab)
  • Scroll down to Java ...
  • Click the blue underlined Disable text link there
  • Consider disabling Flash and others too
• Firefox 3:
  • From the Tools menu, choose Add-ons
  • Click Plugins on the top right
  • Scroll down the list til you see Java Embedding ...
  • Click on it to select it
  • Click the ( Disable ) button on the right
  • Scroll down the list til you see Java Plug-In ...
  • Click on it to select it
  • Click the ( Disable ) button on the right
  • Consider disabling Shockwave Flash and others too
  • Close the Add-ons window
• Firefox 4:
  • From the Tools menu, choose Add-ons
  • Click Plugins on the left
  • Scroll down the list til you see Java Plug-in ...
  • Click the ( Disable ) button on the right
  • Consider disabling Shockwave Flash and others too
  • Close the Add-ons window
• Opera 10: (thanks to Daniel Bergqvist)
  • Go to opera:config#Java|Enabled (if clicking that link doesn't work, copy/paste it into a new tab)
  • Uncheck the Enabled [ ] checkbox
  • Click [ Save ]
  • Click ( OK ) to dismiss the dropdown sheet
  • Choose Quit Opera from the Opera menu
  • Relaunch Opera
• Safari and WebKit nightlies:
  • From the Safari menu, choose Preferences...
  • Click the Security (with lock icon) in the top row
  • Uncheck [ ] Enable Java
  • Close the Preferences window (titled Security at this point)

Disabling Flash, though it has fewer vulnerabilities than Java, will likely cause sites to load faster, since much more network/CPU is wasted by all the Flash ads that sites have these days. I disable Flash everywhere but Safari and run ClickToFlash (the 1.6b9 beta works fine) to selectively run Flash on video sites like Hulu and YouTube.

Disabling Java will not only increase security (by avoiding all the above-mentioned Java vulnerabilities) but it will increase performance as well because your browser won't waste any network time downloading Java applets, nor will it waste any CPU time running them.

Increase your browsing security and speed. Disable Java Now.

There's been much consternation recently about the supposed stability and reliability of HTML5 due to the InfoWorld article link-baitingly-titled W3C: Hold off on deploying HTML5 in websites. The article interviews W3C interaction domain leader Philippe Le Hegaret and quotes him saying things like:

"... it's a little too early to deploy it [HTML5] because we're running into interoperability issues ..."

and

"I don't think it's ready for production yet,"

and

"The real problem is can we make [HTML5] work across browsers and at the moment, that is not the case."

I know Philippe, and I have a feeling that the quotes in the InfoWorld article may either be abbreviated versions of what he actually said, somehow taken out of context, or perhaps reflecting a "glass is half empty" perspective.

Regardless, those quotations, taken on face value, are provably false.

HTML5 Has Plenty Of Interoperability Today

First, there is plenty of HTML5 with zero interoperability issues (e.g. DOCTYPE, meta charset, most of the semantics, and many APIs too.) that you can safely use across browsers.

I know because I've been coding with HTML5 and teaching workshops on practical HTML5 for over a year. I found there was so much that was usable cross-browser that I was inspired to write my first book and video tutorial about it: HTML5 Now - ~46 page booklet, 2.5+ hours of video, ~100 page PDF eBook - the vast majority of which covers HTML5 features that work reliably today.

And yes, just as there are parts of HTML5 that interoperate very well, there are also some features you can't yet depend on. I choose to focus on the positive here ("glass is half full") and perhaps that's the difference in perspective. Regardless, it's irresponsible to make a general statement stating it's too early to deploy HTML5, because there's plenty of HTML5 you can safely deploy right now.

But you don't have to take my word for it.

Using HTML5 Today In Production

David Recordon wrote a nice post on Facebook titled simply Using HTML5 Today where he listed some features from HTML5 and related technologies that Facebook is using, right now, live, on their production site, including:

• HTML5 <video> element
• HTML5 History interface - helps maintain cleaner more robust URLs even when using AJAX to change the state of the page.
• Geolocation API - which just over a month ago became a W3C Candidate Recommendation, meaning:

  W3C publishes a technical report as a Candidate Recommendation to indicate that the document is believed to be stable, and to encourage implementation by the developer community.

Facebook is also experimenting with other Web Applications technologies such as:

• Web Storage
• Web Sockets API

Both of which are Working Drafts, the latest public versions of each are almost a year old as of this writing, and should really be updated to the most recent editor's drafts.

More Support For Using HTML5 Today

Many have responded to the InfoWorld article and its chicken-littling of HTML5. Here is some additional reading:

• Remy Sharp: Hold off on deploying HTML5 in websites? (Remy is a co-author, along with Bruce Lawson, of the excellent book Introducing HTML5, so he too knows what he is talking about, first-hand.)
• Dion Almaer: Don't "deploy HTML5"? Thanks again W3C
• CNET: Facebook rebuffs W3C's HTML5 caution
• Philippe Le Hegaret followed up with a a more positive post on the W3C's blog: HTML5: The jewel in the Open Web Platform
• Dion then followed up to that post with a call to arms: HTML5 is a jewel that we need to cut into a weapon.

Yes the battle for the Open Web is not over yet, however, the least we can all do is not FUD our own efforts.

Let's eagerly advocate what works well today, while honestly admitting what is still "in progress". As time goes by and more and more of what's "in progress" becomes "what works well today", web developers will see the consistent trend and get the message.

Photo by Pascal Finette:

Embedded here as an HTML <object>, with all of the text of the image nested inside marked up with hCard. You can even Add Steve Jobs 1979 to your Address Book.

Via Mike Shaver's retweet of Pascal's tweet.

I just arrived at O'Reilly's Sebastopol Campus where they're holding a *Camp event on the open web, eponymously named "Open Web Foo Camp". A few days ago I was speaking with Jim Dwyer of the New York Times about the Federated Indie Social Web vs. sharecropping and site death (more on that in another post), and he happened to ask me (probably because I mentioned it in passing), what is, or what do I mean by "the open web".

At the time I didn't have a working definition, but apparently provided an answer good enough for a self-described non-technical journalist to "get" what is the open web. Here's roughly what I told Jim, off the top of my head:

For me the Open Web is about the ability to openly do three kinds things:

1. publish content and applications on the web in open standards
2. code and implement the web standards that that content/apps depend on
3. access and use content / code / web-apps / implementations

Each of these merit a bit of expansion.

Publishing content and applications

The web has brought with it the biggest revolutionary advance in access to publishing since the printing press. It's quite cheap to buy a domain (a few dollars per year), cheap to buy web hosting service (a few dollars per month), easy to open up a built-in or free text editor on any popular computer to write some HTML and CSS, and use a built-in or free FTP (or other file-transfer program, e.g. scp) to publish your content to the web, at a permalink instantly viewable by millions world-wide.

Yes, with a few dollars a month and a few hours, you can publish and reach hundreds of millions of people. I call that revolutionary.

This ability to openly publish depends on a few things:

• open formats for freely publishing what you write, photograph, video and otherwise create, author, or code (e.g. HTML, CSS, Javascript, JPEG, PNG, Ogg, WebM etc.).
• domain name registrars and web hosting services that, like phone companies, don't judge your content.
• cheap internet access that doesn't discriminate based on domains

A few non-open-web examples:

• formats: many media formats controlled by patent pools, e.g. even publishing H.264 video is at the mercy of "MPEG LA". Supposedly it's free to publish free video, but if you want to publish video and charge for it, you have to pay them royalties. Not open.
• domain name registrars: just this week, NIC.ly, the registrar for .ly domains, shut down vb.ly due to text referring to adult content and offensive imagery [according to conservative Libyan Islamic Law]. Not open.
• censored internet access: numerous countries censor access to the internet.

All of those are examples of threats to the open web. For more on how H.264 is not open, and neither is Flash, despite all the rhetoric from Apple and Adobe respectively, I highly recommend reading Ben Ward's blog post: Understand The Web.

Coding and implementing web standards

The open web is fully dependent on browsers, search engines and other applications and services being able to code and implement all the web standards (formats, protocols) that authors use to publish their creative works. The browsers, search engines and other such "user agents" in turn depend on web standards that are:

• openly documented, in this day and age, on the web itself.
• freely accessible. there should be no charge to view a web standards specification.
• unencumbered by patents, either patent-free, or available under unconditional royalty free licenses.

Most W3C and IETF standards for example, meet these criteria. So do open public-domain based efforts like microformats.org and other modern "social web" standards (too many to list here, maybe I'll add a few links later :)

A few non-open-web examples:

• Numerous ISO standards. E.g. ISO-8601, the standard that web standards have subsetted to represent dates and times on the web. You have to pay to download ISO-8601 and other ISO standards. Not open.
• Flash. Not anyone can freely implement support for the constantly evolving Flash format. It's Adobe's proprietary code, with who knows how many patents that apply to it (no I haven't checked).

Thankfully, as the process of how we develop web standards themselves evolves, we get better and better at both providing very openly accessible and implementable standards, as well have become more sensitive to attempts to thwart the opennness of web standards.

Access to content and applications on the web

The web, and the internet as a whole, depends on the independence of content and addressing (i.e. domain names) and devices. You must be able to serve and access any kind of content across any domain name on any web device. Obviously not all devices will be capable enough to support all formats, but that should have nothing to do with the nature of the content itself.

This open access depends on the open ability to browse and use any web page or application (i.e. URL) on your:

• web browsing device
• internet service

And this must be without censorship per domain, URL, content-type, or nature of the content.

A few non-open-web examples:

• The aforementioned countries that censor access to specific sites.
• Internet Service Providers that do traffic shaping, or block certain types of internet traffic. For example, cable company consolidation threatens this open access.

Much of this "open access" requirement for the open web is also known as "net neutrality", and championed by none other than Senator Al Franken as the foremost free speech issue of our time.

And that's my rough working definiton of what is the open web. In summary:

• open content and application publishing
• open ability to code and implement the standards that such content depends on
• open access to content, web-applications, web standards implementations (browsers), and the internet.

I think this is a good starting point for a discussion of what is the open web, and look forward to feedback and learning from my colleagues, both online, and in-person this weekend.

Translations

• Qu'est-ce que le Web Ouvert ? by Olivier Le Monnier

Referencing Articles

• 2011-09-27 The Guardian: Why Facebook's new Open Graph makes us all part of the web underclass by Adrian Short (originally posted on his blog 2011-09-25 It’s the end of the web as we know it)

Despite the previous evening's liquid fueled lateness, somehow I woke up refreshed. It was as if some things were resolved that I didn't know needed to be. For the first time since I'd left home, I managed to do a half hour of yoga.

After a quick grapefruit, coffee, and apricot juice breakfast, Hannah and I went to the local farmer's market and picked up some vegetables, fresh bread, a spinach quiche, and a slice of apple pie.

The spinach quiche kept us going while we each took care of a few things, bills, various random tasks, and last minute organization of a pub meetup later that night, detailed on Plancast and announced via Twitter naturally.

The Crown Tavern

We arrived about 15 minutes early at The Crown Tavern and started sampling their drinks. One or a few at a time, various London friends started showing up, some I'd seen a couple of days ago, some I hadn't seen in over two years.

As geeks often tend to, we compared and discussed cameras while waiting for our food. Despite the limitations of their Sunday menu, there were several vegetarian choices. I started with the tomato mozzarella basil salad and mini crabcakes, and had the lentil veggie burger for my main. It was all quite delicious, far beyond what I would've expected from a tavern. They even made a proper ristretto espresso with Illy coffee, served in a small eponymously branded cup.

Canals And Jazz

We were quite stuffed and the pleasant evening called for a walk. A few folks headed home but the rest of us walked along a long canal where we saw quite the variety of small cafes, street art, new developments, as well as houseboats docked to the sides.

Eventually we found ourselves in Dalston where Matt, Hannah, RJ, and I would make our stand for the rest of the evening.

Never before had I seen such a mixed hive of sharp dressers, a spectrum of hipsters, and the oddly out of place chav clusters. Fortunately we arrived early and managed to grab a couple of small tables. As the place filled up it was far too easy (and tempting) to snap over-the-shoulder shots of the amazing array of individuals.

The band was quite good. As relaxed as the day had started out, a bit of live jazz was the perfect closer.

Scrambles And Site Updates

Hannah and Jamie were wonderful hosts and I finally had the opportunity to repay them just a bit for their hospitality. With ingredients we'd picked up from the farmer's market and some fresh eggs, I made a mixed vegetable scramble for brunch that seemed to go over quite well.

Since I first attended SXSW in 2002, I've noticed that web conferences tend to be a bit like balls, the kind you dress-up for. Especially if you're speaking, but even if you're just attending, you know that lots of new people will be inevitably asking you for your site and taking a look. Conferences provide perhaps the necessary impetus to finally make progress on personal site updates that we've been procrastinating.

Both Hannah and I were feeling this; she didn't really have much at her own domain, and my site was far too cluttered since I'd started rebuilding it at the beginning of the year. Her challenges were mostly around coding and configuration, and mine were clearly design and layout. It was a perfect opportunity to do some pair web development, on both our personal sites, in parallel.

No Plan, Just Improv

We didn't really have a plan, we just knew that together we had the skills to accomplish what each of us wanted to accomplish, and that if we just started riffing on our existing work, together we might each actually get to where we each of us wanted to be.

As I cleaned up bits and pieces of my markup in preparation for a redesign, Hannah worked on a visual design for her site. Pressed for time, rather than create a brand new site from scratch, or take the time hassling with WordPress install, setup, configuration, theme authoring, she decided to go with using Tumblr for her "content management", though she had concerns about design and layout flexibility. I'd done enough Tumblr theme hacking to assure her that it would be no problem to convert her Photoshop visual designs into Tumblr template HTML + CSS.

This is something I'm seeing more and more designers do (e.g. Dan Cederholm, Timoni West) - that is, switch from either blogging software like WordPress or their own custom site code, to using Tumblr for their content (served at their own domain names - a nice Tumblr feature), with a hand crafted template to their liking.

Hannah and I worked late into the night. She gave me a simple grid to implement, then I got stuck on site headers/footers which she quickly addressed. She created the various images for her overall design, and I helped her put them in all the right places with CSS: backgrounds, fixed position elements, little cute affordances.

Things wouldn't look quite right, so Hannah measured precise pixels in her designs, which I helped translate to CSS rules on the respective elements. Our absence of a precise plan provided just the freedom of expressivity/creativity that we apparently needed, and everything just flowed from one thing to the next.

We successfully completed client-side bits of our respective redesigns (as much as any web design can be "complete" as opposed to a state of constant iterative improvement).

Of Domain Names And Propagation Magic

Just one thing remained, which was setting up the necessary A-record and C-name (yes, exactly, the whats?) for Hannah's personal domain to show her nicely styled Tumblr content, without doing any redirects. We tried following the Tumblr directions and couldn't quite get things working. Likely something to do with DNS propagation, or her hosting provider, or her domain name provider.

Server configuration is definitely much more of a pain than any front-end work. So many fragile moving parts, where the slightest mistake in any of them can break something, or leave open a security flaw, or both. Not exactly a paragon of usability.

We decided to call it a night. Over the next 24 hours I read up on some of the more ridiculous details of A-names etc. (which, if you want to understand some of the more arcane aspects of how domain names work at all, you might consider doing), propagation times, timeouts etc., and figured out a series of steps that should help us accomplish our goals.

That next night, from my hotel in Brighton (more on that transition in part 4), I IM'd with Hannah who was still in London, and we walked through the steps necessary to setup her site to serve her content, and in addition, a way to use her own hosting provider to quickly serve static content such as her style sheets and stylistic images. We got it working as best we could and waited for all the necessary bits to propagate (something nearly any DNS related change requires). By the next morning, with just 24 hours to go til dConstruct, it all worked.

Site reconstruction, complete.

I just participated in the CSS Working Group telcon for the first time in a while (like Hixie, I'm not a huge fan of telcons). We're giving CSS3 Color last call commenters a week to follow-up on our responses, then arranging a "transition telcon" with the W3C Director to move the spec to Proposed Recommendation (PR)!

Thanks to co-editor Chris Lilley for writing up the email responses to last call commenters and the CSS3 Color Disposition of Comments as well.

Special thanks to co-editor David Baron for developing the CSS3 Color Test Suite, running the tests, and writing up the implementation reports which demonstrate that we've had interoperability (what you need to transition to PR) for quite some time, with Firefox leading the way with CSS3 Color.

Recently my blog was added to the Planet Mozilla aggregator thanks to a nomination from Asa Dotzler. So if you're reading this post over there, hello, and thanks for having me. Be forewarned that not all my posts will be about open web standards - you'll likely see a bunch of personal posts as well. It is my personal blog after all and I do tend to write about whatever is on my mind.

Four months ago I started contracting at Mozilla to work on several standards in the areas of Web Applications UI and Web Identity, as well as reach out to the broader web design and development communities on those same topics.

Rather than provide a broad but shallow list of things done etc., I thought it would be more interesting to take a moment to explore one particular question that I've heard from the community from time to time, not in these exact words, but in general:

Why do CSS spec improvements take so long?

The answer involves quite a few things, but perhaps it is time we start talking about them, maybe even just one or a few at a time.

First and foremost, editing W3C drafts is a royal pain.

Nevermind the process (or typical W3C member costs!) for joining a working group, or (re)chartering a working group, or IP battles, or even the frustrations of getting CVS working with W3C's setup (I'm working on making that less painful, see related resource: W3C CVS For Dummies), all of which contribute to an excessively high barrier to materially participating in the evolution and iteration of W3C specs ( = very few people have the time, money, focus, persistence to do so - I for one am fortunate that Mozilla, with their mission of supporting the Open Web, has hired me to do so, and thus I am able to spend a lot more time on them).

Here are three recent CSS drafts that I've edited as a case study to explore some of the challenges.

• CSS Style Attributes - a fairly simple draft, documenting how the 'style' attribute in HTML works (and in any other language that has one as well). This draft is largely stable, done, etc. and now just waiting to be officially published as a Candidate Recommendation (CR). What's left?
  • According to the W3C Process Document, numerous specific tasks - most of which reasonably asks for public documentation.
  • In this case, the last remaining step is to schedule a teleconference with the W3C Director, presumably to make sure the aforementioned steps have been taken, and then get a date for publication. Typically the W3C staff contact for the working group arranges the telcon. If they or the Director are particularly busy, this can take potentially weeks.
• CSS Color Module Level 3 - this draft is more extensive, but has already been through a Candidate Recommendation stage, then taken back to Last Call, and with a test suite and implementation reports demonstrating interoperability, it should be ready for publication as a W3C Proposed Recommendation (PR). Once again, the W3C Process regarding a PR provides the necessary steps, which typically require a teleconference with the Director, again, arranged by the working group's W3C staff contact. Similar challenges to the previous draft, however, more of them, as PR is a higher bar to meet. Because there's more work to do to get CSS3 Color to PR, I've decided to keep a list of the CSS3 Color tasks to PR on the CSSWG wiki.
• CSS3 Basic User Interface Module - this draft was published as a CR many years ago, and since then, browsers have implemented most of it, as well as a few other CSS UI related features such as the 'pointer-events' property. However, CSS3 UI faces much more difficult obstacles than the other two drafts - it's no longer officially in scope for the working group.

For the first two drafts, CSS Style Attributes and CSS3 Color, what's taking so long now is essentially a set of bureaucratic checks and balances. I'm fairly confident they'll be taken care of in days or at most a few weeks.

For CSS3 UI, the problem started because in the previous rechartering of the W3C CSS Working Group, doing work on "user interface" was completely dropped. That means that until the group recharters again, it can't publish any official drafts pertaining to that subject area.

Fortunately, the W3C CSS Working Group discussed rechartering at the recent meeting in Oslo, and decided to re-include "user interface". With any luck the rechartering process will complete relatively soon, and by sometime in November, the groups will be able to officially publish a new draft of CSS3 UI. Until then, you'll have to just keep up with the above-linked unofficial public editor's draft.

And these are just three out of numerous CSS3 drafts in development. Each of which requires a diligent editor (or a few!), familiar with W3C's CVS setup, that regularly updates the editor's draft, and keeps up with emails, issues, etc. related to their draft(s), nevermind figuring out what specific next steps need to be taken to advance the draft(s) along in the W3C's process. It's a lot of work for just a few people, no wonder it takes so long for CSS drafts to make progress!

I hope that sharing some of these details has helped at least provide a better understanding of some of the challenges with pushing standards forward at W3C. I think there's a lot of potential for improvement. For example, the CSS Working Group has been doing a lot to encourage more community participation, e.g. with requests for contributions to test suites to help demonstrate interoperability.

There's probably more that we could do though, with spec-editing, and perhaps with help simplifiying the overall process as well. If you've got suggestions for the CSS Working Group, or W3C in general (e.g. regarding the W3C's processes), perhaps write up a short blog post, and tweet it, referencing @csswg and @w3c respectively.

After wrapping up a successful CSS work week in Oslo it was time for a long weekend in London catching-up both with good friends I mostly hadn't seen in years and a new friend I'd recently met in the states. Flying from Oslo to London, it really struck me how much closure a few days had brought, both personal and professional, as well as getting unstuck on a number of things.

Slot Machine Connectivity

It's possible that turning off my mobile data access (due to pricey international data roaming on AT&T, even with a prepaid plan), and thus curtailing nearly reflexive reading of Twitter, Foursquare check-ins, and IM had helped encourage better focus, and thus greater productivity.

You might think that AT&T's terrible San Francisco reception would provide a similar experience, but it doesn't. There's something very different about predictable rare but good service (e.g. only connecting via wifi, or briefly turning on international data), vs unpredictable spotty service.

The unreliability of the latter almost encourages more reflexive mobile usage, perhaps not unlike a five column slot machine - you never know how many bars you'll get, and when 1-2 bars turn up, it gives you irrational hopes of maybe scoring 5 bars, so you keep playing.

The answer then, would be to only hangout places that give you predictable connectivity (cell and/or wifi, none or a lot), so you know what to expect and can plan/use your time respectively. Amazing, or perhaps appropriate, how total lack of connectivity on a flight can inspire insights into the psychology of connectivity.

After a brief delay at Heathrow waiting for the express trains to resume running from an unscheduled shutdown, I headed to last.fm headquarters to meet my host for the long weekend and give an informal talk.

Hannah had asked me to give a brief Friday afternoon "Techmosis" guest talk to their engineers (a last.fm tradition) on a topic of my choice, and then join them in their regular Friday Halo session. I sent her my list of crazy topics and for some reason she agreed. Armed with nothing but a white board and a web browser, I launched into an exploration of Six Crazy Projects that I'd been working on during the past couple of years. In rough logical temporal topical order:

• bi-glot programming - creating a language+framework for writing/running code natively simultaneously in Javascript and PHP: CASSIS
• Babylonian calendaring mistake - what happens when you correct a Babylonian calendaring mistake? You get a NewCalendar
• base 60 numbers - What do you come up with when you need a print-safe character compression scheme for an algorithmically reversible personal URL shortener? A NewBase60
• short URLs - How do you make good (or at least harmless) short URLs? With an algorithmically reversible personal URL shortener: Whistle
• personal publishing - personal publishing software including a server-based Twitter client: Falcon
• identity and authentication - By learning from the real-world successes of the rel="me" microformat and Twitter Sign-in, and using them as design and architectural foundation, how do you enable using your personal web identity for signing-in and authentication? RelMeAuth

The last.fm folks asked some great questions, most of which I had reasonably good answers for. Afterwards I asked if they were interested in a couple more crazy projects, and they encouraged me to go on:

• remapping the planet with octal geo coordinates - an octal-based geo-coordinate system that works well as the basis of base 64 algorithmically reversible geo-shortlinks: OctalGeo
• print+URL safe base 64 numbers - a base 64 counting system that is print-safe and URL-safe for encapsulating a pair of octal digits in a single character: NewBase64

And this was when things got really fun (if you're into nerdy topics like algorithmic geo short URLs :).

Cubespace Debut

Last.fm's Robin Lisle asked about how would you use OctalGeo to specify not just a location like an address or building, but also a floor or level of a building, giving the example of tall skyscrapers in Japan (or potentially any city).

At this point I had to go completely off-web and on-whiteboard, because I had thought about the problem of compressing three-dimensional geo-coordinates (even collected some ideas on paper and text files) but had yet to write anything up on my wiki, or frankly, even run the ideas by anyone else.

I briefly whiteboarded the derivation of Cubespace. Just as OctalGeo subdivided 2D geo-coordinates into ever shrinking 1/64th squares for each digit (3 bits for x and 3 bits for y), I drew a cube, subdividing edges into 4 segments each, faces into 16 squares each, thus a whole cube into 64 subcubes, and announced: this is when we enter Cubespace.

By encoding 2 rather than 3 bits per coordinate, in 6 bits we can represent 3 dimensions rather than 2. Simple math (or "maths" as the English call it, as Jeremy would teach me two weeks hence).

By combining the two encodings, it is possible to first use OctalGeo digits to specify a square of area on Earth (WGS84 projection) that is no wider than the twice the desired absolute value altitude, and then switch to CubeSpace to refine that square with a cube of the same size, half above, and half below the surface, with a digit for each 1/64 subcube of additional precision desired.

And suddenly it was time for drinks, eats, and a movie.

Scott Pilgrim vs. His Mistakes

The next 24 hours started simply enough. Drinks with last.fm friends at a local pub, then a burrito (yes, in London, and it was quite good), followed by a viewing of Scott Pilgrim vs The World. With each viewing of Scott Pilgrim, both new lessons found, and old lessons reinforced.

Pilgrim's character makes plenty of mistakes in the movie, and even more are hinted at in his past. But despite these mistakes, he still "wins" and gets the girl. Why?

Because it's just a movie, that's why. That being said, many of the film's characters are reasonably well written, and some of the points made resonate with at least my personal experience - video-gamesque fights notwithstanding (though watching the movie repeatedly has made it hard not to see blinking bonus numbers appear and float upwards every time I complete some task or new achievement).

Despite it being an oft-repeated startup cliché, you can learn a lot from your mistakes. You can learn a lot from others' mistakes too. Everybody makes mistakes. What matters is how you deal with them, what you do next.

Making The Best Of Failure

Still exhausted from a week of CSS working group and spec-writing intensity, I slept in, again. And I'd also just run out of laundry. Lucky for me my hosts Hannah and Jamie had a washing machine so I started a load. No matter I thought, the plans I'd made with my other friend were only vaguely scheduled sometime that day/afternoon, and I went ahead and communicated where I was at / up to.

About 4pm I finally started making my way over to meet up and messaged as such, within minutes I got an angry response about it now being kinda late. And now that sinking feeling: in an ambiguous situation, I had guessed wrong, misinterpreted, probably miscommunicated, screwed up, and made the person I was going to meet angry and upset.

Oh I tried being flexible, suggesting alternatives, hoping to salvage something, but despite effort and apologies, apparently my implicit scheduling failure had caused too much misunderstanding, thus, shut down again. Sometimes it's good to know when to give up on a bad situation I suppose, and let failure be.

About that learning from mistakes thing. You can often learn more about someone by how they deal with mistakes than their making (or avoiding) of mistakes in the first place. And when you make a mistake that impacts someone else, and deal with it as best as you can, you can learn a lot about them by how they respond to your making and dealing with a mistake.

In this case, it became clear that from my perspective, not only was I apparently given a very low margin for error, but no chance of recovery in case of error. I wouldn't figure out the further implications (best to just not hangout with this friend) for a few days hence.

Pouring Into A Dance

My hosts graciously dealt with my resultant emo-implosion at having not only screwed something up with an apparent delay, but hurt someone's feelings at that, and my sense of helplessness from being unable to fix it.

We ended up having a nice late lunch out, and afterwards, Hannah took me out to a couple of pubs. Suffice it to say I sampled plenty of cider, vented most of what I felt at the first pub, and by the second pub was looking forward to what/how could I do better, both eventually and tonight.

After a swift evening walk, stopping only to pet a kitty on someone's stoop, we arrived at The Lexington, where sampling whiskey is what one does. Hannah introduced me to a friend of hers from out of town, who was supposed to crash with Hannah but couldn't, apparently since I was crashing there.

Still, we did hit it off a bit, discussing the politics of science, and either Neuromancer or Snow Crash. I'm pretty sure it was Neuromancer, but by this pint, details had become fuzzy.

Upstairs there was a band or DJ playing, which was apparently sufficient motivation to pay the £10 cover and head on up. I don't remember the name of the whiskey we ordered. No matter, there was a dance floor.

We must have spent an hour or two talking and dancing, mostly dancing, some dancing with talking. I do appreciate someone who can dance for the fun of it, and enjoy it for what it is. It was simple, it was nice, it was right, and it sure wasn't going anywhere else.

Sometime in the singleton hours, I met up with Hannah, who was also ready to call it a night. I bid my new friend goodbye with a quick kiss on the cheek. Later I'd find out that she's apparently a popular comic writer and illustrator, and the fact that she'd actually bothered to spend that much time hanging out, talking, and dancing with me may have meant something. Again, I failed to pick-up on subtle (or perhaps not so subtle) cues from a girl. Yet we had nerdy discussions, and we danced, and for that I was happy.

As I walked off the dance floor and left the club with Hannah, everything slowed down, became heavier, and the evening's energy evaporated. We caught a cab, the framerate dropped to about 5-10 frames per second. Somehow I made it up stairs and under the covers on an air mattress and promptly fell asleep.

Today is the 256th day of the year. If you start the year with day 0, today is # 255 = FF hex = 11111111 binary = the highest unsigned integer you can represent in 8 bits = #8bitday.

I tweeted this last year (created a wiki page), and then discovered Programmer's Day on Wikipedia (I think someone on Twitter pointed it out). Apparently it's an official professional holiday in Russia!

While I certainly appreciate the recognition (being a programmer myself, and having thought in 8 bits for far too many years), I prefer a broader appeal - hence, "8 Bit Day" in recognition of 8 bit art & culture in general, which anyone can appreciate.

This year the most prominently public celebration of 8 bit culture is no doubt the movie Scott Pilgrim vs. The World (and the graphic novels) which was packed full of 8-bit (and some 16 bit) video game references.

If you're an 8-bit fan and a Halo fan, you might also enjoy the 8-bit Halo machinima videos on YouTube.

Finally, if you like 8-bit music, AKA "chiptunes", check out:

• 8bitpeoples free MP3 downloads
• last.fm radio: 8bit or chiptunes

Enjoy 8 bit day. If you have one, dig out your old Atari 2600 (or pick up a new Atari Flashback 2 Plug and Play), and play some classic Combat.

Almost forgot - during the last day of meetings, Håkon introduced a few of us to some Norwegian press who wanted to interview CSS working group members. I spoke with digi.no (@digi_no) and Computerworld Norway. They both wanted to know about the past, present, and future of web standards and innovation. Innovation in standards has been accelerating the past few years, to the point where even web developers can be surprised, like the recent confusion and fuzziness over what is HTML5.

The first interview was by Harald Brombach of digi.no: "Legger grunnlaget for vakrere webapps". It's in Norwegian (as you might guess from the title), so here's an English translation via Google Translate: "Paves the way for more beautiful webapps".

It's impressive how much the quotes survived the round-trip human-computer translation (me speaking English, Harald translating into Norwegian, and Google translating back).

The second interview I did together with Chris Lilley of W3C which was quite fun - it takes some of the pressure off to be interviewed as a pair. What was particularly fun was contrasting our different backgrounds and experiences, Chris at W3C and myself as a developer at Microsoft, Technorati, and as an independent standars advocate. In Norwegian: "HTML5 er sikrere enn Flash", and again, the Google translation: "HTML5 is more secure than Flash."

I was particularly pleased that Computerworld Norway picked up on the "Open Web Apps" terminology. If the press can get behind a term, especially across languages, perhaps it's something we can get behind to better explain the difference between what is actually HTML5, and the broader open web applications platform that HTML5 is a core component of.

Transatlantic flights force an ever rarer disconnect from the digital collective. Even the strongest of focusers can make use of the resultant executive function surplus; the rest of us, even more so. However, this British Airways flight has Iron Man 2 (on demand), which I haven't seen. Let's how that works as background.

It's been an amazing 20 days. new CSS, boots, London adventures (and mis), the best dConstruct ever, closing with a beautiful week of holiday (mostly) in Brighton, and the first @MozPub.

I'm looking forward to returning home, seeing those important to me, making necessary changes with renewed energy, and being inspired to create, once again.

This all started nearly three weeks ago.

Acclimation

Despite a badly delayed SFO departure, thanks to Heathrow's amazingly efficient new Terminal 5 (and having carried-on all luggage), I made my connection to Oslo, and a swift train straight into downtown.

My colleague and fellow CSS Working Group compatriot of many years Daniel met me at the train station. We had dinner and shared our recent trials and tribulations, both professional and personal. Short relationships that were never meant to be, and longer ones, doomed from expectations of entitlements. If your loved one makes you cry, stand-up for yourself and walk away (same thing is true for a job, though you may have more recourse there). Respect starts with self-respect. If they demand ever more entitlements, or act more like a spoiled brat than a courageous partner, leave them. Let them grow-up on their own time, if they ever do.

CSS Working Group

Heads and hearts just a bit clearer, we jumped into three solid days of W3C CSS Working Group meetings. The meetings were hosted by Opera Software thanks to Håkon Wium Lie. Our work didn't stop there. Dinners and discussions carried late into the night, thanks to the shared apartment that Tab Atkins rented out for us for a week. All the minutes (day 1, 2, 3) and raw IRC logs (day 1, 2, 3) are publicly available, posted promptly on @CSSWG. A few of the accomplishments that I'm particularly happy with:

• Better W3C editor source control set-up instructions. Thanks to Elika and David Baron putting up with my bitching about CVS long enough to help walk me through getting it working, I wrote up a much more detailed W3C CVS setup, detailing every dumb idiotic problem I ran into no matter how small, and what the fix was. I give you: W3C CVS For Dummies to enable more CSS working group members and invited experts to directly edit developer drafts and advance more CSS3 more quickly. It's on the CSS Working Group wiki and thus my hope is that others will add more tips and notes where they got stuck and how they got unstuck.
• All CSS 2.1 issues resolved (again) - the working group has worked very hard over the years sweating insane levels of details. Often in response to public feedback, but more often as a result of browser vendors iteratively implementing CSS 2.1 more and more precisely, and as a result uncovering holes and ambiguities that might affect only the rarest of pages. To be clear, the latest in progress draft of CSS 2.1 is far more accurate than any previous CSS Recommendation (1 or 2).
• CSS Style Attribute editor's draft - this is a draft I helped edit many years ago, and is one of those critical pieces of documentation that connects HTML and CSS. The group has updated this draft to reflect how browsers work, and nothing more, i.e. what you can depend on. Expect a Candidate Recommendation soon.
• CSS3 Color editor's draft - having finally gotten W3C CVS working, I've begun putting the finishing touches on the CSS3 Color Module. Thanks to David Baron's previous edits, and Chris Lilley's handling of last call comments and the resultant disposition, we're pretty close on this one. Just the remaining details that only someone with OCD could enjoy cleaning up. Well, maybe mostly enjoy.
• CSS3 User Interface Editor's Draft - Having submitted a slew of technical fixes for HTML5, after minor CSS3 Color edits, this is now the key W3C draft I'm focusing on as part of my work at Mozilla. Just one problem: when the CSS working group last rechartered they left out working on UI. So for now, all work CSS3 UI will have to be in the form of a live, unofficial editor's draft that reflects the best we know of current implementations. Again, a very pragmatic draft. Once that looks reasonably solid (even as an editor's draft, I'll start drafting a CSS4 UI with next generation Web Apps UI features.

Not everything went perfectly though. On the last day of the working group meeting, the USB memory stick I'd been using for recent documents (even for my CVS checkout) went bad. I was able to recover some text file fragments, and had recent (days/weeks old) backups, so the loss wasn't too bad, but still disappointing.

Oslo Day Out

Turns out if you sleep only 3-4 hours a night for 3-4 nights in a row, you will crash and sleep right through your alarm clock. No matter, I had planned an extra day in Oslo to walk around downtown and do some shopping. I awoke to the sound of Tab Atkins knocking on the apartment door. He barely missed his flight, they rescheduled him for the next day, so he came back the apartment. Good thing I overslept - no one else was around to let him in.

We went out for coffee, a late brunch, and some shopping. After picking up a few essential items of black clothing at H&M (same prices as in the U.S.), and finding nothing good on sale at G-Star, I checked out a few shoe stores for boots.

New Boots

Ladies, this is an area where you're at a significant advantage - there are way more kick-ass women's boots than men's boots. For some reason boot-makers think guys want either douchey low cut dress boots, or overweight cumbersome boots with cheesy buckles / decorations or impractical laces. Or cowboy boots, which are just not my thing.

Frustrated, I finally asked one store if they knew of any place that sold decent at least calf-height boots for men, and they pointed me to a spot a couple blocks away. We got there minutes before closing time, descended into their basement, where the only people were a couple of bored salespeople.

Even here though, Tab patiently listened to my rants about bad shoe design, all the things obviously wrong with all of their boots. About to give up and leave, I came across a pair of black calf-high boots hidden on the 2nd shelf of an intermediate (not wall) display. When I picked one up I nearly flung it into the air - it was about 1/4 to 1/3 the weight I'd expected it to be. Super-light.

Simple solid black styling, nothing fancy. Goretex water proof. Super-grippy sole. I had to try them on. A pair of European size 41s fit my feet like gloves. They felt like the best hiking boots I'd ever worn, but better fitted, black, waterproof, and light as sneakers. Incredible. Something clicked and I remembered where I'd heard the brand before: Ecco, recommended to me by Phoebe the friendly boot salesgirl I'd met a month beforehand in Portland.

A climber friend of mine had once tweeted about her tradition of buying a new pair of boots after a break-up, break-up boots as it were. Seemed like a good idea in theory, and as I walked out of the boot store wearing my new Eccos, I finally understood what she was talking about.

Dinner and Departures

We wrapped up the evening with a nice dinner at Håkon's place, took nearly the last tram home, and after a fruitless search for laundry detergent, called it a night. Packed early the next morning, David Baron, Tab, and I took the train to Oslo airport where we shared one last lunch together before we departed our separate ways. Philadelphia en route to California for them, while the agent at my gate called out: London - all rows boarding for London.