Adam Newbold's perception of the quality of content on the World Wide Web, 1994 to present3
Semantics. It's the new word of the Web. We're experiencing a cultural, social revolution with this technology and we're totally and utterly unprepared for it. "Web 2.0", they call it. Since 2004, it has become the buzzword, and, in essence, the next bubble. Businesses support it. Consumers support it. Governments are beginning to support it. And yet we're hacking. Every time we use CSS, we hack. Every time we use XMLHTTPRequest, we hack.
1989. Tim Berners-Lee grows tired of being unable to easily access referenced informational documents, so he invents the brilliant idea of "hypermedia", and implements respective protocols to allow linking between documents—HTTP, HTML, and URIs1— thereby initiating the Web we know and love today. It works perfectly for those means, whereby static documents are able to be easily cross-referenced and handled.
2008. Fast forward nearly 20 years. (Yes, it really has been almost 20 years since the Web was created.) We live in a bustling, content-rich, style-rich society. The Web and its associated technologies play major roles in the operation of thousands upon thousands of businesses on a day-to-day basis, and the lives of millions of people over a similar timeframe. Standards have evolved since 1989, with the development of HTTP 1.1, the progression of HTML to version 4.01 and future revisions under consideration, the push for CSS-based design, the creation of XML and an entire community of additional standards surrounding it, and, most recently, the idea that semantics should play a major part in the way the Web—and indeed computing in general—works.
And yet everything is fundamentally the same. We're still using a set of elements to mark up our Web pages that were around in 1989. We're still using the same basic protocol to interact with Websites that was proposed in 1989.
Ladies and gentlemen, it doesn't fit anymore. We've outgrown the Web of the '90s. The spider's dead and gone, and we're left wrestling with its now-tangled and dusty remains.
It was HTML. It was a relatively simple, SGML-defined syntax, grammar, and vocabulary for representing documents transferred via the relatively simple protocol HTTP. And that was just about it. In the early '90s, it was perfect for transferring the technical documents shared within CERN (where Berners-Lee worked). It gave the users options to style and organize content, similar to a manual page, and it added the capability to link to other documents.
We gave it the cookie. It's a simple idea, really. Since HTTP is inherently unable to maintain state (that is, keep track of a user's activities across multiple user-agent sessions—or indeed across multiple page views within the same user-agent session), we decided to store the state on the client. Of course, this came with haphazard security implications (decided upon by whoever implemented cookies first) that said cookies were only registered and available to the domain that initially set them (and optionally under a specified path). And everything worked fine for a while.
But then there was JavaScript. JavaScript donated interactivity to the Web. It meant that things could be animated, and better yet—it gave the developer access to some data, through, for example, cookies. JavaScript was also subject to some arbitrary security measures by software developers, but this was never standardized. And for a long time, this was good enough. The developer gained the ability to play with the user's screen, which was cool, and the Web became just that much more interactive, which was also cool.
XMLHTTPRequest. Perhaps this technology has lended itself the most to creating the interactive, multifaceted Web experience the average user expects today. It is, in itself, a hack. Think about this: HTTP, by definition, does not maintain a persistent connection to the host once a page's content has been downloaded, there was no way to retrieve some content from the server when available and embed it into an already-loaded page (sort of like how one would expect a regular desktop application to work). To work around this, an object was introduced that specifically allowed a developer to make additional client-side HTTP requests in JavaScript (or, well, initially using ActiveX) and get the Web server's response back.
So why are these technologies so detrimental to the current state of the Web? The answer is simple: The Web simply wasn't designed to support them. All of these features are hacked on top of a protocol designed to do nothing but show documents and then link them together. They don't have any security policies and were never audited as such; they were never truly standardized (with the exception of HTML, which is riddled with ambiguity), but rather implemented haphazardly until user-agent developers agreed (in most cases) on internal function.
And there are more. There are more technologies that came up haphazardly. There are more technologies that were never standardized or were standardized much too late. And now we're dealing with the consequences of those mistakes.
At some point in time, consumers and businesses alike began to see the value in bringing semantics to the Web. Making things inherently meaningful would mean that handling data would be simpler and that changing the presentation dynamically would be easier. People began pushing for this semantic presence among nothing other than the hacked-up "style-ized", "interactive-ized" World Wide Web.
This is still happening to date. The problem, of course, is that the Web is not capable of carrying the type of semantics we're trying to give it.
A perfect example of this is the group known as microformats. Microformats describe themselves as "a set of simple, open data formats built upon existing and widely adopted standards"2. This means, essentially, defining semantic properties using the class attribute of (X)HTML tags. What does this mean for the Web? Well, absolutely nothing.
There is a reason that XML namespaces were created using URIs and not just arbitrary identifiers. On a given Website, there is absolutely no way to tell whether a given class (say, vcard— see the hcard microformat) is associated with a microformat or is just some arbitrary class used for a completely different purpose. This means that the semantic quality is only known to the author of the Website, the machine-readable aspect of the specification is irrelevant and indeterminable, and the human-readable aspect is—and has been for years—accomplished using the same means as any other markup.
Let me emphasize this: this so-called format is completely worthless.
And there are a thousand more "standards" like this. There are a thousand more mistakes that people are adopting because they think it represents their content properly.
Don't get me wrong: in many respects, these ideas are good things. People are beginning to really care about representing their content meaningfully. They're currently forced to work within the realm of HTML and HTTP, and there isn't much they can do about that (or so they think).
With business booming in retail sales via the Web and the Web indeed becoming more of a virtual "society" than a mere document transmission mechanism, it is more important than ever to fix the issues of the Web. It is only a matter of time until something irrevocable and horrible happens. It could be a user-agent exploit that facilitates the stealing of millions of users' personal information at once. It could be a problem that breaks the very model upon which the Web was developed, given its relatively inextensible nature (at least, without some incredibly creative hacking).
I realize that working with vendors is not easy. I realize that it is never easy. I realize that adopting new specifications is something that takes years of hard work and persuasion. In many cases, extending the existing standards would be an appropriate action to take. However, in the case of (X)HTML, JavaScript, CSS, and the host of associated technologies that make up the Web, a complete redesign is in order.
The client-side muck that has become of the Web is absolutely appalling. Implementations vary in their behavior immensely, and are riddled with bugs. Imagine if the TCP/IP stack worked like this—communication by computer would be an complete pain in the ass. I cannot stand to see the basic means of communication for so many computer users continue to operate like this.
We need several new things. To begin, we need a new protocol. We need a protocol that can support the interactive experience that Web users expect today; HTTP simply cannot hold up for much longer. (It had a good run.) Secondly, we need a new format for marking up Web-based documents. HTML isn't going to cut it. Next, we're going to need a better way to apply style and form to the documents. We're also going to need a way to assign behaviors to documents to maintain the desktop-application-like interactivity of the "new" Web. And finally, we're going to need an extensive security model to keep everything in check for the future.
Let's analyze these pieces individually:
One of the major factors that has to be taken into account when creating these standards is verbosity. Every behavior, every style must be explained and documented so that user-agent developers are able to understand and implement them consistently independent of platform.
The development of a model that fulfills all of these fundamental requirements will facilitate a more reliable, extensible, and featureful Web experience—for developers, for businesses, for consumers, and for the world in general.
The cracks in the Web are beginning to turn into holes. As we attempt to apply semantics to our current platform, we're encountering issues that are only being resolved with hackish behavior. The time is now to change the Web. To reinvent it. We must create a model for this multifarious communication platform (no longer a simple technical document transfer protocol!) that will reflect both the needs of today and the needs of tomorrow. It is my hope that this document will be the informal beginning to the future Web.
(By the way, if the next-generation protocol should make any provisions for specifying a page's referrer, let's try to spell the identifier correctly.)