You’re probably trying to figure out why anyone would ever use their toaster to browse the Web. Well, chances are good that nobody actually will, but it makes for a better visual.

The next Web-enabled devices

In reality, your television will probably be the next household item to connect to the Internet on a regular basis (no, I’m not talking about Microsoft’s bastard child, WebTV). Through 2006, we’ve already seen a huge increase of on-demand programming which follows essentially the same server/client model as this website. The technology is there, and it’s available, so it’s essentially just a matter of time before it hits the mass market.

What’s after that? Probably your stereo equipment or radio, so you can just stream that Internet radio station through your alarm clock in the morning, and directly into your tired little head.

Let’s not forget work: every piece of equipment that you see as pretty stupid today will be growing much smarter in the next few years: scanners, printers, copiers, fax machines, and the office phone system. While those may not necessarily be connected to the Internet, they may connect to the Intranet using some text-based browser. Heck, some may already do that, and I just don’t know about it.

The Web is about communication

Technology tends to enhance communication, which I think of as the translation of ideas into sensory input. Education, music, chatting, collaboration, business, physical training: all require communication in one of its many forms. As technology keeps moving, I believe we’ll see the progression of the Internet into each of those communication spaces. Guess what that means for web designers? We need to be thinking way ahead of today’s user agents and devices, and toward a future that holds a much wider variety of visual and auditory communication methods.

Modal representation

I believe the way of the future is modal representation: change of the way something is perceived, depending on the method in which it is accessed. The most important piece of this is our good old friend, separated content and presentation. If we have content that can be transformed with an external file or mechanism, all we have to do to make our website compatible with new technologies is to create a presentation for that mode (or, if possible, allow for the same output across multiple modes). Of course, I’m not bringing up anything new here: you’ve probably heard about the CSS @media rules.

HTML is not the final answer

However, let’s be honest with ourselves: HTML has been around a long time, and is very much widespread as I’m sure you know. HTML is not the future though; it simply cannot be changed fast enough to keep up with changing requirements, although it is usefully generic in that it can display and provide guidelines for document formatting. Even assuming that manufacturers would/could update their browsers every month to keep up with specifications changing in that same time frame, that still wouldn’t be fast enough. That’s where the concept of even using HTML is at fault when it comes to forward compatibility.

What I’m saying is this: separating your content from your presentation is good, but it’s not going to be the end-all. Eventually, your site will have to be revamped for future web user agents, simply because HTML is not flexible enough to allow for possibilities that the future holds. Let me clarify: HTML alone is not flexible enough. People will say that you’re future-proofing your website, but in reality, you’re just making it very easy to update and maintain, two very worthy causes. Thing is, we don’t know how people will be developing the Web in the future, but it’s safe to say that it won’t be HTML as we know it.

What does the future hold?

So what is the future? Well, I think the W3C is on the right track with XHTML: HTML conforming to the XML standard so that it can be extended with namespace, transformed using technologies like XSL, and presented to the user agent with technologies such as CSS. The “problem” with the Web is that it constantly evolves. People find new ways to do things and present information all the time, and the HTML standardizations just can’t keep up. I think there should be a self-describing, extensible standard for markup, transformation of that markup, and formatting of that markup.

Browsers are holding back the Web

What’s holding us back? In a word: browsers. At the time of this writing, Internet Explorer 6 comprises the majority of all user agents in use today, and it doesn’t support the capabilities of reading XHTML as XML, which is really the benefit in the first place (not code standardization, as many like to think). Not that other browsers are doing all that great either, but the standards haven’t been around, so I won’t be too hard on everyone. Here’s the thing: browsers should be very ignorant as to what’s happening with the markup, transformation, and formatting of a document, but right now they do a lot of their own interpretation of the standards. Markup is “validated” against a browser’s own cache of a DTD, rather than comparing against the referenced DTD in the doctype, or the included namespace in the case of XML. So, rather than self-describing, we have a very static language.

The same goes for CSS: browser manufacturers spend forever implementing the changes from version to version of CSS. Why not have a “doctype” for CSS as well, that can reference a specific standards document that defines how selectors should be interpreted, how the box model should work, etc. That way, whenever an update to the standards document comes out, web developers can just point to the new DTD, and the browser will theoretically be able to render it. Sure, this is a lot of work on the part of the browser manufacturer, but to really expand the Web’s horizons, I think that sort of functionality is necessary.

The shining light of the group is XSL, which already does its job pretty much as well as you could expect. Transforming XML isn’t always an easy task, but virtually any transformation is possible using the XSL sub-languages. However, the standard could once again define how selectors should be interpreted, as I’ve described for CSS above.

Back to modal representation

If XHTML/XML, XSL, and CSS worked the way I mention above, then developers would be able to transform the XML, and format that output with CSS based on the current mode. So, while your recipe website will be graphically enhanced and will have news, interviews, etc. when viewed in a “normal” browser, when someone navigates to it from their oven or refrigerator’s browser in the future, the first things they’ll see are a recipe search tool, and a list of popular recipes. This brings up another conundrum: eventually, we’ll have to have more than just modes, we’ll have to have sub-modes, or classes, of user agents. For example, a future mode type may be “appliance”, which is useful because you’ll probably know that it’ll have a lower resolution screen, and not as sophisticated of an input scheme as a normal computer, but you’ll definitely need to be able to differentiate an “oven” appliance, a “refrigerator” appliance, and a “dishwasher” appliance.

The future for now

For now, what do you do? True XHTML isn’t really a viable option at this point, since certain browsers which will remain unnamed can’t have it served as xml. Internet Explorer. What I suggest for the time being, so that it will be easy to transition into XHTML, is to use HTML 4.01 Strict and enforce lower case tags and quoted attributes internally. If you stick to that, the transformation from HTML 4.01 to basic XHTML in the near future shouldn’t be too difficult. Make sure you separate your content from your presentation, as that is the crux of the matter in the first place.