HTML is Not Enough (but it Should Be), Part 1
02/10/2011

Back in the 80s, when a physicist by the name of Tim Berners-Lee crafted the first versions of HTML, the web browser, and the web server, he envisioned a system for sharing documents and information over the Internet. The idea was to create a means for people all over the world to not only view documents that were linked together (via "hypertext"), but for them to actually contribute to and create content as well.

Fast forward thirty years and it becomes painfully obvious that HTML is simply not enough. In order to create a website you have to master any number of technologies and standards. One example is CSS for styling the site. But even that is not sufficient, because nobody wants to develop a site from scratch because it's just too hard to keep editing the HTML itself every time you want to make an update to the site. And writing or customizing server-side software to automate content management requires programming skills which are generally beyond the reach of most people.

That's why modern content management systems have sprung up. Most notably, there's the trifecta that I like to call Joopalpress. Or would that be Wormlapal?

Hello, browser-based editing!

Suppose that, back when HTML was newly hatched, website editing was built right into the browser? It turns out that this was kinda the case. In fact, the first web browser, a program built on NeXT called WorldWideWeb (which later became the less ambiguously appellated Nexus), actually included a WYSIWYG editor, but there was no easy way to push updates and new files from the browser to the server; files had to be edited directly on the server or transferred there somehow (usually using FTP). What's the use of editing the page if you can't “push submit to make it stick”?

The ability to edit right from within the browser has actually been built right in to web browsers for some time. For example, click on this paragraph and start typing. See how you can just change the text to your heart's content? That's enabled by a simple attribute added to the paragraph tag (contenteditable="true"). It's supported by every browser from IE 5.5 onward. The problem is actually saving the changes back to the server. You can change this paragraph all you want, but refreshing the page will throw all your changes out.

So, what does it take to actually change the file on the server? I can think of a couple of things:

1. Authentication so that only authorized users can make changes
2. Some buttons in the browser to indicate when to save the changes you've made to the file

If these two basic features had been built in to the first web server, I'm pretty sure that many existing content management systems simply wouldn't exist. The browsers, or extensions to them, would have become the de facto web development and content management environment themselves.

Various iterations of this concept have existed throughout the years, but it usually involved some bloated application that you installed on your computer that did a really lousy job of approximating what the page would look like while allowing it to be edited. One notable example is the (thankfully) now-retired Microsoft FrontPage, which added extensions to the server that allowed the program to change the files on the server when a user was authenticated.

The CMS Era

The term CMS, or Content Management System, is overly broad. But in the industry it is implied that if you are using a CMS it enables browser-based site management with little or no technical skill. I suppose a text editor and an FTP client also make up a content management system, but you just need the skills to manually create all the HTML yourself.

Modern CMS systems like Joopalpress owe their existence to the fact that content management was not built into the web from day one. The problem is, in order to customize these systems you need to have a deep understanding not only of HTML, but of PHP or Perl or Java or Python or, well, more PHP to actually get anything done.

Part 2 of this series will explore how going back to the fundamentals of HTML and adding just a few additional features (that should have been there to begin with) for authentication and browser-based editing opens up a whole new world of web design, without the huge CMS overhead. In other words, we want to make HTML enough to deploy basic websites again. Only now, they will be easily managed right from within the web browser.

*****