Steve Vinoski, an architect at Basho Technologies, has been working with distributed systems and complex projects for a long time, first as a tentative explorer and then leaping across to Erlang when it seemed right. Seventeen years as a columnist on C, C++, and functional languages have given him a unique viewpoint on how developers and companies are deciding whether and how to take the plunge.

Highlights from our recent interview include:

• From CORBA/C++ to Erlang — “Every time I looked at it, it seemed to have an answer.” [Discussed at the 3:14 mark]
• Everything old is new again — “Seeing people accidentally or by having to work through the problems, stumbling upon these old research papers and old ideas.” [7:20]
• Erlang is not hugely fast — “It’s more for control, not for data streaming.” [16:58]

• Webmachine — “[It's what you would get] If you took HTTP and made a flowchart of it … and then implement that flowchart.” [23:50]

• Is Erlang syntax a barrier? [28:39]

Even if functional programming isn’t something you want to do now, keep an eye on it: there’s a lot more coming. There are many options besides Erlang, too!

You can view the entire conversation in the following video:

Related:

• Subscribe to the free Code podcast through iTunes

We sat down last week to discuss the many huge changes CSS3 is bringing, from improvements to old capabilities to completely new tools for animations, transforms, and layout. The continuous rate of change and the size of the specification are driving him to serialize the next edition of the Definitive Guide, releasing it in pieces. Developers can work from familiar foundations, but reach new destinations. The declarative strength of CSS3 lets you create presentation by describing it, and that style keeps proving more powerful.

Highlights of the interview include:

• CSS3 brings big changes in font capabilities, letting you send fonts to users [discussed at the 2:30 mark] and sites putting those improvements to work [15:50].
• The many options can make choosing a set of parts seem difficult [discussed at the 4:21 mark], but JavaScript shims that add support for CSS properties can make it easier to use properties even if browsers haven’t come around to them [6:08]
• Which of your features are like rounded corners? Will progressive enhancement let you worry less about those? [Discussed at the 6:55 mark.]
• More and more CSS modules apply its declarative approach to behavior, and changes over time. [Discussed at the 8:28 mark.]
• The new stuff that really has Eric excited? Layout improvements, using pieces designed for explicit layout rather than turning floats into a layout system. [Discussed at the 12:36 mark.]

You can view the entire conversation in the following video:

Related:

• Subscribe to the free Code podcast through iTunes

That stack, despite solving many problems, brings two new issues: it’s bulky, and there are a lot of problems that even that bulk can’t solve.

Two proposals at last week’s Balisage markup conference examined different approaches to working outside of the stack, though both were clearly capable of working with that stack when appropriate.

Shrinking to MicroXML

John Cowan presented on MicroXML, a project that started with a blog post from James Clark and has since grown to be a W3C Community Group. Cowan has been maintaining the Editor’s Draft of MicroXML, as well as creating a parser library for it, MicroLark. Uche Ogbuji, also chair of the W3C Community Group, has written a series of articles (1 2) about it.

Cowan’s talk was a broad overview of practical progress on a subject that had once been controversial. Even in the early days of XML 1.0, there were plenty of people who thought that it was still too large a subset of SGML, and the Common XML I edited was one effort to describe how practitioners typically used less than the XML made available. The subset discussion has come up repeatedly, with a proposal from Tim Bray and others over the years. In an age where JSON has replaced many data-centric uses of XML, there is less pressure to emphasize programming needs (data types, for example), but still demand for simplifying to a cleaner document model.

MicroXML is both a syntax — compatible with XML 1.0 — and a model, kept as absolutely simple as possible. In many ways, they’re trying to make syntax decisions based on their impact on the model.

Ideally, Cowan said, the model would just be element nodes (with attribute maps) containing other element nodes and content. That focus on a clean model means, for example, that while you can declare XML namespaces in MicroXML, the namespace declarations are just attributes. The model doesn’t reflect namespace URIs, and applications have to do that processing. Similarly, whitespace handling is simplified, and attributes become a simple unordered map of key names to values. The syntax allows comments, but they are discarded in the model. Processing instructions remain a question, because they would complicate the model substantially, but the XML declaration and CDATA sections would go. Empty element tags are in, for now …

Some of the pieces that raised controversy with questions were the current proposal to limit element and attribute names to the ASCII character set, and the demise of processing instructions. I mostly heard cheers for the end of draconian error handling, though there were memories of the bug compatibility wars of an earlier age reminding the audience that it could in fact be worse, or weirder.

There may be, as Cowan noted “no consensus on a single conversion path” to or from JSON, but MicroXML takes some steps in that direction, suggesting that JSONML should be able to support round-tripping of the MicroXML model, and JSONx could work for JSON to XML.

While I suspect that MicroXML has a bright future ahead of it in the document space, it seems unlikely to take much territory back from JSON in the data space. MicroXML doesn’t seem to be aiming at JSON at all, however.

Overlapping information and hierarchical tools

Very few programmers want to think about overlapping data structures. In most computing cases — bad pointers? — overlapping data structures are a complex mess. However, they’re extremely common in human communications. LMNL (Layered Markup and Annotation Language), itself a decade-long conversation that has suffered badly from decaying links, has always been an outsider in the normally hierarchical markup conversation. There may be conflicts between XML trees and JSON maps, but both of those become uncomfortable when they have to represent an overlapped structure.

Wendell Piez examined the challenges of processing overlapping markup — LMNL — with tools that expect XML’s neat hierarchies. Obviously, feeding this

[excerpt
[source [date}1915{][title}The Housekeeper{]]
[author
[name}Robert Frost{]
[dates}1874-1963{]] }
[s}[l [n}144{n]}He manages to keep the upper hand{l]
[l [n}145{n]}On his own farm.{s] [s}He's boss.{s] [s}But as to hens:{l]
[l [n}146{n]}We fence our flowers in and the hens range.{l]{s]
{excerpt]

into an XML parser would just produce error messages, even if those tags were angle brackets. Piez compiles that into XML, which represents the content separately from the specified ranges. It is, of course, not close to pretty, but it is processable. At the show, he demonstrated using this to create an annotated HTML format as well as a format that handles overlap gracefully: graphics, using SVG (or here as a PNG if your browser doesn’t like SVG).

Should you be paying attention to LMNL? If your main information concerns fit in neat hierarchies or clean boxes, probably not. If your challenges include representing human conversations, or other data forms where overlap happens, you may find these components critical, even though making them work with existing toolsets is difficult.

However, at the in-progress Balisage conference, it’s clear that markup remains really good at solving a middle category of problems, where its richer structures can shine without creating headaches of volume or complication. In the past, Balisage often focused on hard problems most people didn’t yet have, but this year’s program tackles challenges that more developers are encountering as their projects grow in complexity.

XML and JSON

JSON gave programmers much of what they wanted: a simple format for shuttling (and sometimes storing) loosely structured data. Its simpler toolset, freed of a heritage of document formats and schemas, let programmers think less about information formats and more about the content of what they were sending.

Developers using XML, however, have found themselves cut off from that data flow, spending a lot of time creating ad hoc toolsets for consuming and creating JSON in otherwise XML-centric toolchains. That experience is leading toward experiments with more formal JSON integration in XQuery and XSLT — and raising some difficult questions about XML itself.

XML and JSON look at data through different lenses. XML is a tree structure of elements, attributes, and content, while JSON is arrays, objects, and values. Element order matters by default in XML, while JSON is far less ordered and contains many more anonymous structures. A paper by Mary Holstege focused primarily on possibilities type introspection in XQuery, but her talk also ventured into how that might help address the challenges presented by the different types in JSON.

Eric van der Vlist, while recognizing that XSLT 3.0 is taking some steps to integrate JSON, reported on broader visions of an XML/JSON “chimera”, though he hoped to come up with something more elegant than the legendary but impractical creature. After his talk, he also posted some broader reflections on a data model better able to accomodate both XML and JSON expectations.

Jonathan Robie reflected on the growing importance of JSON (and his own initial reluctance to take it seriously) as semi-structured data takes over the many tasks it can solve easily. He described XML as shining at handling complex documents and the XML toolset as excellent support for a “hub format,” but also thought that the XML toolchain needs something like JSON. He compared the proposed XSLT 3.0 features for handling maps with JSONiq, and agreed with Holstege and van der Vlist that different expectations about the importance of order created the largest mismatches.

Hans-Jurgen Rennau had probably the most optimistic take, describing a Unified Document Language – not a markup syntax, but a model that could accomodate varied approaches to representing data. His proposal did include concrete syntax for representing this model in XML documents, as well as a description of alternate markup styles that help represent the model beyond XML.

I don’t expect that any of these proposals, even when and if they are widely implemented, will immediately grab the attention of people happily using JSON. In the short term they will serve primarily as bridges for data, helping XML and JSON systems co-exist. In the longer term, however, they may serve as bridges between the cultures of the two formats. Both approaches have their limitations. XML is cumbersome in many cases, while JSON is less pleasantly capable of representing ordered document structures.

JSON freed web developers to create much more complex applications with data formats that feel less complicated. As developers grow more and more ambitious, however, they may find themselves moving back into complex situations where the XML toolkit looks more capable of handling information without the overhead of vast quantities of custom code. If that toolkit supports their existing formats, mixing and matching should be easier.

Metadata, content and design

Markup and data types are themselves metadata, providing information about the data they encapsulate, but Balisage and its predecessor conferences have often focused on metadata structures at higher levels — the Semantic Web, RDF, Topic Maps, and OWL. So far, this year’s talks have been cautious about making big metadata promises.

Kurt Cagle gave the only talk on a subject that once seemed to dominate the conference, ontologies and tools for managing them. His metadata stack was large, and changing near the end of the work to include SPARQL over HTTP. If Semantic Web technologies can settle into the small and focused groove Cagle described, it seems like they might find a comfortable niche in web infrastructure rather than attempting to conquer it.

Diane Kennedy discussed the PRISM Source Vocabulary, an effort similar in its focus on applying technology to solve a set of problems for a particularly difficult context. The technology in the talk was unsurprising, but the social context was difficult, describing a missionary effort, to bring metadata ideas from a very “content first” crowd to magazines, a very “design first” crowd. Multiple delivery platforms, notably the iPad, have made design first communities more willing to consider at least a subset of metadata and markup technology.

Markup and programming language boundaries

While designers are historically a difficult crowd to sell semantic markup, programmers have been a skeptical audience about the value of markup — especially when “you got your markup in my programming language.” There are, of course, many programmers attending and speaking at Balisage, but the boundaries between people who care primarily about the data and those who care primarily about the processing are a unique and ever-changing combination of blurry and (cutting) sharp.

A number of speakers described themselves as “not programmers” and their work as “not programming” despite the data processing work they were clearly doing. Ari Nordstrom opened his talk on moving as much coding as possible to XML by discussing his differences with the C# culture he works with. In another talk, Yves Marcous said “I am not a programmer” only to be told by the audience immediately “Yes, you are!”

XML’s document-centric approach to the world seems to drive people toward declarative and functional programming styles. That is partly a side-effect of looking at so many documents that it becomes convenient to turn programs into documents, an angle that is very hard to explain to those outside the document circle. However, the strong tendencies toward functional programming emerge, I suspect, from the headaches of processing markup in “traditional” object-oriented or imperative programming. The Document Object Model, long the most-criticized aspect of JavaScript, exemplifies this mismatch (compounded by a mismatch between Java and JavaScript object models, of course). As jQuery and many other developers know, navigating a document tree through declarative CSS selectors is much easier.

Steven Pemberton’s talk on serialization and abstraction examined these kinds of questions in the context of form development. Managing user interactions with forms has long been labor-intensive, with developers creating ever-more complex (and often ever-more fragile) tools for forms-based validation and interactivity. Pemberton described how decisions made early in the development of a programming discipline can leave lingering and growing costs as approaches that seemed to work for simple cases grow under the pressure of increasing requirements. The XForms work attempts to leave the growing JavaScript snarl for a more-manageable declarative approach, but has not succeeded in changing web forms culture so far.

Jorge Luis Williams and David Cramer, both of Rackspace, found a different target for a declarative approach, mixing documentation into their code for validating RESTful services. The divide between REST and other web service approaches isn’t quite the same as the declarative / imperative divide, but I still felt a natural complement between the validation approach they were using and the underlying services they were testing.

A series of talks Tuesday afternoon poked and prodded at how markup could provide services to programming languages, exploring the boundaries between them. Economist Matthew McCormick discussed a system that provided documentation and structure to libraries of mathematical functions written in a variety of programming languages. Markup served as glue between the libraries, describing common functionality. David Lee wanted a toolset that would let him extract documentation from code — not just the classic JavaDoc extraction, but compilers reporting much of their internal information about variables in a processable markup format.

Norm Walsh started in different territory, discussing the challenges of creating compact non-markup formats for XML vocabularies, but wound up in a similar place. Attempting to shift a vocabulary from an XML format to a C-like syntax introduces dissonance even as it reduces verbosity. After noting the unusual success of the RELAX NG compact syntax and the simplicity that made it possible, he showed some of his own work on creating a compact syntax for XProc, declared it flawed, and showed a shift toward more programming-like approaches that eased some of the mismatch.

If you’re a programmer reading this, you may be wondering why these boundaries should matter to you. These frontiers tend to get explored from the markup side, and it’s possible that this work doesn’t solve a problem for you now. As conference chair Tommie Usdin put it in her welcome, however, Balisage is a place to “be exposed to some things that matter to other people but not to you — or at least not to you right now.”

I talked with Seth Ladd, a web engineer and Chrome Developer Advocate at Google who’s working on Dart, but still, I’m happy to say, interested in JavaScript itself. He’s been working with larger projects and larger teams figuring out how to build bigger, faster, and more complex applications than most of us care to dream about.

Seth’s constant push – “we can do better” – takes a hard look at where we are today with web programming, acknowledging decades of improvement but looking hard for the next best thing.

Highlights from the full video interview include:

• Speed – is JavaScript fast enough yet? [Discussed at the 2:12 mark]
• 60 frames per second – can the browser look that smooth? [Discussed at the 3:21 mark]
• Dart – Structure, tooling, and reaching both JavaScript and C++ programmers [Discussed at the 6:27 mark]
• “Dart compiles to modern JavaScript today” [Discussed at the 9:16 mark]
• “JavaScript is becoming the bytecode of the Web” – many languages compile to JavaScript [Discussed at the 11:16 mark]
• View Source isn’t what it used to be – is Github the answer? [Discussed at the 12:07 mark]

You can view the entire conversation in the following video:

Fluent Conference: JavaScript & Beyond — Explore the changing worlds of JavaScript & HTML5 at the O’Reilly Fluent Conference (May 29 – 31 in San Francisco, Calif.).

Save 20% on registration with the code RADAR20

Related:

• What is Dart?
• Subscribe to the free Code podcast through iTunes

I talked with Yahoo architect fellow and VP Bruno Fernandez-Ruiz (@olympum) about the possibilities Node opened and Mojito exploits.

Highlights from the full video interview include:

• “The browser loses the chrome.” Web applications no longer always look like they’ve come from the Web. [Discussed at the 02:11 mark]
• Basic “Hello World” in Mojito. How do you get started? [Discussed at the 05:05 mark]
• Exposing web services through YQL. Yahoo Query Language lets you work with web services without sweating the details. [Discussed at the 07:56 mark]
• Manhattan, a closed Platform as a Service. If you want a more complete hosting option for your Mojito applications, take a look. [Discussed at the 10:29 mark]
• Code should flow among devices. All of these devices speak HTML and JavaScript. Can we help them talk with each other? [Discussed at the 11:50 mark]

You can view the entire conversation in the following video:

Fluent Conference: JavaScript & Beyond — Explore the changing worlds of JavaScript & HTML5 at the O’Reilly Fluent Conference (May 29 – 31 in San Francisco, Calif.).

Save 20% on registration with the code RADAR20

Related:

• Subscribe to the free Code podcast through iTunes
• The vision behind Yahoo’s Cocktails platform and Livestand app

A couple of years ago I’d hear standard complaints like “people don’t read any more,” “customers would rather surf than read,” and “piracy just makes the whole Web thing impossible.” On the bright side, we all agreed that “at least we don’t work in newspapers.”

This year, attendees seemed more excited and definitely more positive about the future. Maybe it was Macmillan’s successful spat with Amazon. Perhaps it was just an adjustment to the lowered expectations of the economy, and a sense that those who’ve survived this far are past the disaster.

I suspect, though, the anxiety reduction has something to do with publishers having more hope about the three things all financially-driven publishers need to function:

1. An audience
2. Something to sell that audience
3. A market for selling those things

The audience (1), seems to be coming back, if it ever really left. I didn’t hear much about “the decline of reading” this time, but I did overhear “texting is awful, but at least it’s text.” While the Web may not have helped book sales, it does seem to have made basic literacy much more clearly relevant.

Based on the conversations I had during TOC (an admittedly unscientific sample), publishers’ hopes are reviving in large part because they expect the iPad to create a market for their goods (3) on terms they mostly like better than Kindle’s terms. Apple’s design appeal has created a market for its devices, while Apple’s thirst for control over their products has created a controlled market with simple terms, prices publishers (mostly?) control, and relatively little piracy. Publishers have craved something like this for the last decade.

I worry that many of the conversations I heard at TOC assumed that publishers already had (2), something to sell, under control. After all, publishing does an excellent job of creating books — all kinds of books, on all kinds of subjects, for all kinds of readers. Convert them to ePub or PDF or maybe even an iPhone app if necessary, and we have something to sell, right?

For the moment, yes. There is still demand for traditional books presented through shiny new devices. Millions of readers love and understand books, yet might be willing to make the transition from bound paper and ink to an electronic rendition. Unlike most previous ebook readers, however, the iPad puts its content in direct competition with the Web as readers have come to know it. Unlike the Kindle, for instance, where browsing felt like an afterthought that would use up expensive connectivity, connecting to the Web is more central to the iPad experience than is reading books.

The competition from the Web won’t just be free content versus paid content, but a matter of user experience. Will readers be content to follow a long text, or would they rather switch applications to something more interactive, with more connections between content?

I saw two talks at TOC that seemed to get to the heart of this: Pete Meyers’ Book Meets Tablet: 10 Ways to Enhance Your iPad Books, and Bob Pritchett’s Network Effects Support Premium Pricing. (Neither talk, alas, is available online, though their slides are available at those links.)

Meyers looked at the challenges of competing with the far more interactive Web world, of keeping users interested in the content that publishers hope they will buy. His 10 suggestions, presented as sketches, were all about ways to use the new format to pull readers into the book. Some of it is supplementary material, some of it is allowing readers to personalize their books (with notes), and much of it pushes into new territory that takes a more interactive turn than books have allowed. My personal favorite was renegade sidebars and footnotes, which take familiar asides in books and let them cause more interesting trouble.

Pritchett took a somewhat different course, talking about the possibilities of breaking books out of their covers and bundling them into more comprehensive applications. Pritchett has something of an advantage going into this, as Logos Bible Software works in a field, Bible study and religious reference, where consistent hypertext referencing has gone on for hundreds of years. Concordances, citing chapter and verse, and an immense collection of explorations along similar pathways give Logos a rich field for creating new products by connecting different resources. Establishing those connections and making their use comfortable is a challenge in itself, but opens possibilities no single project can have.

(Beyond the confines of the TOC conference, I also highly recommend Craig Mod’s Books in the Age of the iPad, which steps back even further to question the differences between books and the iPad experience.)

So should publishers be happy? Is the iPad a much-needed life preserver for publishers on stormy seas?

Well, yes. It gives them access to a market of people who are interested in buying things from them, who are familiar with their goods, and who likely have the spare cash and time to enjoy them. The harder question, though, is what we publishers are going to do with that life preserver. Is it just going to keep us afloat, or are we going to swim to new places? Most of us, I suspect, should be practicing our swimming.

(And of course we should all worry about Apple’s fondness for control leading to limiting what its partners are allowed to do or striving to abolish its competition through aggressive patent suits. This is definitely a salvation worth questioning.)

We’ve been working for a while on a new way of ensuring that our content will continue to have a life after it’s been set down in print. Last week, we released Learning Rails: Live Edition, the pilot for what we hope will become a common way to ensure that our customers can get current content from us, even if it’s not yet time for a new edition.

The Live Edition is presently available as an Ebook (PDF, Mobi, and ePub) bundle, and the updated content will also be available through Safari Books Online and eventually print on demand. Customers who buy a Live Edition will get all the updates to the book up until the next new print edition of the book, when the cycle will start again. (For Learning Rails, customers will get all the updates for the upcoming 3.x version of Rails.)

Live Editions follow a different process. Instead of a long wait for a slow new edition, the model is “release early and often.” Authors can quickly respond to reader feedback and errata immediately, rather than filing it away for a reprint or a new edition.

Right now, Live Editions are built as an extension of our normal DocBook publishing process. Authors do have to make their updates in markup, rather than Word or OpenOffice. This may be unfamiliar to some authors, but gives them the power to do things like add or remove index entries as the book changes, and gives them a quick path to seeing PDFs in final form.

We plan to create more Live Editions in the near future, starting with topics where change is constant and having the latest information is the critical feature.

The iPad is all about consuming content, but most of the conversation about that content has seen it in traditional silos:

• Audio, through iTunes
• Video, also through iTunes
• iPhone apps (and now iPad apps), through the App Store
• Books, through iBooks
• The Web, the most open of these options.

The last of those options, however, can incorporate all of the rest – even the iPhone applications. Given the space on the iPad screen and the reported speed of its A4 processor, web design is actually the easiest way to create applications for the iPad.

Web design? On the iPad? Wasn’t that the bad idea Apple originally had for the iPhone, before they were overwhelmed with requests for a real SDK?

Well, yes. The early iPhone development environments felt maybe too sandboxed. A lot of features now available in Mobile Safari were only starting to develop, and key tools for connecting to features of the iPhone not typically found then in web browsers (vibration, accelerometer, geolocation) didn’t exist. Learning Objective C made sense at the time.

Today, things have changed. With support from tools like jQTouch, it’s shockingly easy to create apps that feel like they belong on the iPhone using HTML, CSS, and JavaScript. With PhoneGap, you can reach out to features like vibration, accelerometer, geolocation. What’s more, PhoneGap lets you target your application to multiple platforms, including Android and Blackberry, so you’re not even locked into Apple’s tightly-controlled universe.

For a quick tour of how this works, see Bill Peña’s tutorial. For a lot more detail, though still 160 pages, see our recently released Building iPhone Applications with HTML, CSS, and JavaScript. Despite massive rust on my web skills and no experience with iPhone development, I was able to create a functioning, if basic, iPhone application in three hours, and have it running on the iPhone Simulator in twenty more minutes.

Moving to the iPad shouldn’t be difficult. As the PhoneGap folks tweeted:

for those unsure, iPad is @phonegap compatible out of the box.

There are, of course, ways Apple could make this difficult. They could have locked web-based apps into the iPhone size, but fortunately that doesn’t seem to be a problem. They could also block PhoneGap based applications from the App Store, as they once did, though they seem to have
gotten over that a few months ago. Even if they were to cause trouble, however, it would just block one possible revenue stream – the web browser itself would still be open for business. I don’t think even Apple can close that down.

Apart from the joy of being able to say “I don’t have to learn Objective C”, the web approach has tremendous advantages for probably 80% of the applications people the iPad seems built for. The layered approach of HTML, CSS, and JavaScript makes it easy to pour content into templates, decide how those templates will look, and what interactivity they will have. Done right, it’s a much more maintainable approach as well, making it easy to change the look or add interactivity without having to break into the underlying content again. Adding content or reaching out to content elsewhere on the web is easy. Toolkits already make the shift from traditional web browsers to device development easy. We’ve come a long long way since the first glimmerings of a slow and creaky Dynamic HTML appeared on the landscape.

I expect music and to some extent video to stay in iTunes or similar venues. Terrified book publishers who want their DRM will likely stay in the iBooks zone, though hopefully Apple will let braver publishers in there without DRM. Customers will expect to find “books” there. It’s also clear that there will always be applications, notably games, which demand native code – Objective C on the iPad – to achieve the fastest possible response time, draw intricate graphics, or bind tightly to iPad features. There’s a future for all of those things, in their particular venues.

But for “content”, especially content that combines text with audio, video, pictures, and interactivity, web-style development has a tremendous advantage.

Arise, web developers! Our time has come to dominate!

Then, suddenly, HTML was incredibly boring. The dot-com bust was part of that, but a more fundamental change doomed the conversation: Microsoft dominated the space. Whether because of the dominance of Windows, the technical quality of key innovations like Dynamic HTML, or the disappearance of Netscape into AOL, the stark reality was that Internet Explorer ruled the browser world. Outsiders asking Microsoft for improvements to Internet Explorer invariably heard that Microsoft would be willing to upgrade IE “when our customers ask for it” – which was an almost polite version of no.

As a result, the last decade, even for those of us who turned to Mozilla, Opera, Safari, Chrome, or other browsers, has been one long exercise in making the most out of tools that took their last major steps in the late 1990s. There was enough in HTML 4.01, Cascading Style Sheets 2, JavaScript, XML, HTTP, and XMLHttpRequest to keep us busy, especially as users acquired higher-speed connections and faster computers. There was also constant frustration with browser limitations, driving the development of more flexible plugin approaches like Flash and Silverlight, though none of them succeeded in replacing the traditional Web, however dull it might have become.

Today, though, the HTML conversation is reborn. Standards development around HTML seems to actually have a chance of influencing user experience in the browser, and Microsoft itself is participating in the HTML 5 conversation despite still holding roughly two-thirds of the browser market. While Microsoft’s market share is only slowly eroding, developer mindshare seems to have shifted decisively to the band of WHATWG upstarts, Microsoft’s competitors.

The reason for this, I think, is that HTML 5 clearly has a bright future in a place that Microsoft can’t presently block: mobile web browsers. When I ask people about the future of computing, the word I keep hearing in their answers is “mobile“. Even if it’s small now, it has a much greater effect on how people evaluate what’s coming.

Microsoft has a mobile presence, certainly, but it’s hard to argue that it has anywhere near the visibility of the iPhone, or even the Android. Mobile web browsing has kept Opera going for years, but the iPhone and Android give Apple and Google much more visibility for their HTML 5 work, and Apple’s decision to keep Flash off the iPhone in particular gave developers further cause to rethink their dependencies. (The WebKit browser engine these share will also be integrated with Blackberry soon, and is also on the Palm Pre.)

In the mad rush to build mobile applications, HTML 5′s competition isn’t even desktop web browsers, but other mobile development toolkits. As my co-worker Keith Fahlgren put it recently:

Speaking from personal experience, I’ve had a lot more fun writing an HTML5 application based on CSS3, the database API, and jQuery that runs out of the box on all of the hot mobile platforms than I ever would have had writing some silly Objective C app for a locked down App Store (or Java for an open one).

This creates a whole new world for the “where should HTML go?” conversation. Web developers certainly have pent-up demand for new features, but previous conversations about revising HTML always foundered on the “but will Internet Explorer support it?” question. Today, when that question feels less important, the ice is finally breaking. (Microsoft is even participating in HTML 5, though it’s not yet clear how committed they are to implementation.)

It will doubtless be years before developers can safely deploy fully-featured HTML 5 sites without concern for older browsers, but for the first time it is plausible that changes to HTML will find wide adoption, and hope is rising. That hope, of course, brings its own risks. I can’t say the HTML 5 process has done credit to either the W3C or the WHATWG – it feels to me like an ugly scramble – and there are plenty of specific decisions that deserve careful questioning. That the broken process is actually important to people, however, is a huge sign in itself that HTML is relevant once again.

After years of quiet, it’s worth paying attention again!