HTML is Not Enough (but it Should Be), Part 2
02/16/2011

In part 1 of this series we explored the origins of browser-based site editing and some of the things that were lacking in HTML from the beginning. This time, we're going to talk about some specific features, things like editing text and images, making new pages, and how to manage forms. But first we'll take a bit of a detour to talk about the difference between design and content.

It must be noted that I'm not talking about web design here. I'm talking about web content. These are two very different animals. Web design has to do with layout, colors, general look and feel stuff. What font are you going to use, where. These things need to be established by a design professional (or someone with a good eye for design) to match a particular company or person's identity, but once that identity is established you don't want to muck with it. And if you want a "proper" site absolutely none of that style information is actually in the HTML.

So I'm completely ignoring the style of a site for this discussion. I simply don't care, at least in this context. In the end, information is information, and how it is presented is less important than the actual data itself. If you're browsing a reasonably modern website and are running Firefox, try going to the View menu and selecting "Page Style > No Style." What is left is the stuff I'm talking about. You see text, images, links, and maybe form elements. I suppose we could throw in other media like videos or audio or whatever, but mostly it's just images.

The web should have made it easy to manage all of those things from the browser, and web servers should have been able to talk to the browser to authenticate users and make changes from the beginning.

I blame Berners-Lee

Really, I do. He got most of the way there, but failed to complete those last critical elements. But then again, why develop something when you have a reasonable workaround? For a physicist, shelling in to a server, firing up your editor of choice and making changes to the HTML directly is child's play. So I guess I'll let Tim Berners-Lee off the hook this time.

The rest of us may not be quite so fortunate in our aptitudes. It's just easier to type and format and save using a Microsoft Word-like environment. My mom owned a phototypesetting company when I was growing up, and she had these huge VariTyper systems with green-screened terminals she and her staff would type away on. The results were stunning, but she actually had to type what I would call inline styles for everything. Special code for bold, or a specific font name, or underline this, kern that, leading, you name it, it was all right there on the screen (LaTeX anyone?). And after a while of doing this, it was like the Matrix. You don't see the code. You just see blonde, bru... I mean, you just see a beautifully formatted document.

When so-called "desktop publishing" came along, it killed my mom's business. Now anyone could fire up MS Word and create badly designed documents full of typos and every font known to man! Who needed a professional typesetter and layout designer anymore? Really, it was about having the ability to use a "What You See is What You Get" (WYSiWYG) editor to avoid actually typing any special code to format text. The newfangled personal computer had the power to provide a graphical interface for managing formatting and style, as well as displaying something that looked pretty much like the printed page. And that made all the difference. A secretary could now create documents for a fraction of the cost.

Finding the Middle Ground

Graphic design went through a bit of a dark ages in the 90's as a result of all this. Because everyone thought if they could do it, they should do it. That all spilled over into web design as well, but fortunately now we're seeing something of a renaissance in design (thank you, Apple). People are once again realizing that design is important, but they still want control over their online content.

The middle ground comes when the designer can specifically target what is editable and how it should be edited, only giving the content manager the tools they need to get the job done, nothing more. Separation of style and content is critical here since the design is sacrosanct, and exposing any design elements to the content manager is asking for trouble. You'll have Comic Sans cropping up all over your beautifully designed site.

The trick is actually marking what is editable from the HTML -- that's the web designer's job -- but only exposing the editability from the web browser when the content manager is logged in. The web browser would then allow the various marked items to be edited from within the browser, and could then push back changes to the server when the content manager hits some button. Ideally, the web browser itself would have the ability to do basic rich text editing, as well as image selection and minor editing (cropping, sizing, etc.). Unfortunately web browsers are too dumb to do any of this. As are web servers. They have to work together, after all.

So our solution should allow this, somehow, while still allowing the web designer all the flexibility needed to make truly unique and interesting sites.

There is, however, one more feature that kinda slipped through the cracks. Forms.

Form what?

I remember the first time, back in like 1996 (I know, I was late to the game), that I tried to implement a web form. It was easy! Open form tag like so: <form>. Stick in some inputs, a submit button, close the form, et voilà! A lovely form.

Too bad it didn't do squat.

Turns out you have to do something special on the server to handle the form. HTML is not enough. You can do it in plenty of ways, but every single one of them requires some script or program on the server side. Perl, PHP, or Python, pick your poison.

That first web server should have done something by default, and allowed the web designer to set some basic parameters. Send an email to this address, or save the results to this file. Basic stuff.

At the time, there was no way to know exactly what a form should do, so the HTML simply provided a means of gathering data, as well as some methods (GET and POST) for sending that data back to the server. It was assumed that you or some programmer would then do something special with the data, such as loading it into a database or saving it to a flat file. No way to know, and I understand that.

But I still think it was an oversight not to provide some basic methods out of the box. This oversight spawned plenty of forms processing startups, most notably Wufoo, not to mention a plethora of various forms processing scripts.

Wrapping up

Text, images, forms, oh my! I think we have settled on the fundamentals. Next time we'll talk about actually implementing these features into a CMS framework that web designers can use by just extending HTML a touch. And in so doing we'll open up a whole new world of possibilities.

*****