Steve Klingsporn

Subscribe to Steve Klingsporn: eMailAlertsEmail Alerts
Get Steve Klingsporn: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

Markup Is Madness

Markup Is Madness

I've been reading that the first Web page went online 10 years ago. I remember what it was like being involved with software development at that time. My initial feeling was that using markup in a browser was less than optimal because it leaves too much of the presentation details up to the browser, rather than allowing developers to specify absolute coordinates and other necessary attributes for various objects on the page.

After doing much in the way of Web development and design over the past 10 years, I still agree with myself. Markup sucks for anything other than attributing style changes and links in text copy. For this purpose it's arguably easier than keeping track of style runs and keeping them in sync with text as it's being edited.

Markup is messy. It's hard to work with - staring at it for more than a few minutes gives me a headache. Manually coming up with HTML is a tedious exercise in trying something, checking out how it looks in all of the various browsers you support, and continuing your iterations. Not all browsers speak exactly the same dialect or have the same idea of what you'd like to see. Using a good WYSIWYG HTML editor like Adobe GoLive (which produces very nice markup) that generates code compatible across browser versions you select is a good companion to hand-editing HTML. Some of my friends refuse to use an editor, but I can't fathom how long it would take to generate by hand some of the more layout and graphically intense sites expected today.

I used to work with some SGML proponents who were thrilled that they could generate HTML and PostScript versions of their source documents with ease. I wonder how much of their time was spent on figuring out which tags to type instead of improving the clarity and focus of their content. Honestly, it seems like PDF is a better standard for platform and resolution-independent document authoring; what you see on the screen is exactly what you'll see on the printer. Apparently Apple agrees, as PDF is one of the native rendering types in its new Quartz graphics engine. Every application on Mac OS X, when printing, generates a PDF document that's rendered by the printer. Very nice. Regardless, PDF is even harder to write by hand than markup, and not a good choice for the kinds of interactive user experiences that people expect to have. Flash is pretty neat, but not the best choice either. Luckily, HTML, PDF and, Flash can all be viewed simply as renderable media types; they can be embedded or framed by better technologies.

JavaScript or Apple's NewtonScript are neat for specifying online experiences. Note I don't say "Web pages." I believe that what people really want on the Internet is a vast, interconnected, explorable, media-rich user experience where all users can design and build objects and new experiences from within the browsing application itself. The dynamic nature of JavaScript and NewtonScript holds much promise; both sit on a foundation of dynamic objects called frames. A frame is an unordered list of named values that can be strings, floating point numbers, arrays, raw data, or other frames. Apple used this methodology in very nice, new, and exciting ways in its ill-fated Newton series of PDAs in the early 1990s. There's no reason that user-interface development has to be done with strongly typed languages like C and C++ or even Java; most of the logic in building user-interface components and views works very nicely with dynamic interpreted languages with prototype-based inheritance. Scripting.

The markup folks want to extend their domination to the data space. They tell me that XML is the way to go. To introduce a new data type to the world, all you have to do is draw up a cryptic DTD that defines the rules for the data and then generate data files, all using markup tags. I see problems with this for many reasons. Markup text is larger and more verbose than it needs to be. Too much information is revealed about the data and its structure via the DTD, and as most Internet communication goes over the wire unencrypted, this seems pretty insecure. It's also simply too much of a pain in the butt, and way too static to define a DTD for arbitrary data you want to move from point A to point B (I realize that DTDs are optional). XML may be a good answer for configuration or settings files, or for enterprise data exchange in commerce applications, but I don't see developers sticking all their data in tree structures, generating XML from them, passing them to functions in their code that just go ahead and parse the XML back into a tree structure - all to appease the proponents of markup; while XML seems like a neat idea, so far it hasn't lived up to the hype.

This is one of the "property list" XML-based preference files for Mac OS X:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
<plist version="0.9">
<dict>
<key>AutoHideTime</key>

<real>1.000000000000000e+01</real>
<key>DisplayBehind</key>
<false/>
<key>LineLimit</key>
<real>1.000000000000000e+03</real>
<key>LogFiles</key>
<array>
<string>/var/tmp/console.log</string>
</array>
</dict>
</plist>

Here's what the same data would look like in Newton frame format:

{
autoHideTime: 1.000000000000000e+01,
displayBehind: false,
lineLimit: 1.000000000000000e+03,
logFiles: [ "/var/tmp/console.log" ]
}

Obviously, there's little win in terms of readability, ease of authoring, or space considerations in the XML approach. Apple essentially developed a "PropertyList" DTD/XML format for what it pioneered with Newton frames (JavaScript is derived from NewtonScript) in the early 1990s. The result is illegible, but standard! The frame example doesn't require typed data; the XML example has tags that define the types. If you were building a system, which would you choose? Would you bet your company on it? What are the drawbacks? How much time will you spend worrying about the underlying technology itself instead of the problem at hand?

There's much talk about where the Web will be in 10 years. I hope that, by then, the Web is mostly markup-free. While I acknowledged above that marking up style information and links is a perfectly valid use of markup, the Web and the bloated-and-buggy state of today's browsers are glaring proof that using markup is a tedious and resource-intensive solution to a much simpler, and already solved, problem. And don't even get me started about how inefficient it is to open and tear down a socket connection for every resource on the page! Some form of package format for a page and all of its associated resources would do much in the way of sparing network resources, speeding up the time it takes to download a page, and providing a nicer and more appealing user experience.

I encourage you to take a look at alternate technologies like Newton and JavaScript and work on fun experiments of next-generation browsers and networked user experiences as I've been doing. The Web came out of nowhere as the fruit of a handful of individuals' hard work and perseverance; I imagine that the next-generation Web technologies will spring from the same type of entrepreneurial origins. Luckily for all of us, there's plenty of room for experimentation and innovation, and all of these solutions can live parallel to each other. We have whatever tools we like or can create at our disposal, and the only real standard that's mandatory is TCP/IP. May the best new standards win!

More Stories By Steve Klingsporn

Steve Klingsporn is a software designer and developer who
specializes in desktop and portable user
interface and server-side Web development.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.