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.

*****

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.

*****

Using IDs for CSS. What's the thinking?
06/09/2010

Edit: A couple of additional uses of IDs have been added to the bottom of this article. Don't worry, they have nothing to do with CSS.

Okay, I have a pet peeve. Whenever I look at a CSS template or sample code, the CSS is chock full of IDs. Worse yet, a piece of sample code for an image gallery or page widget is styled with IDs. Sure, that works fine for the sample page, but as soon as I want to duplicate that element on a single page on my site, I have to go and replace all the IDs with classes.

Just stop using IDs to style stuff already.

There are a few arguments for using IDs in CSS out there. Here's an example for one, and an article on About.com for another. Better yet, let me Google that for you. The arguments all boil down to this:

• Use classes if there's more than one instance on the page
• Use IDs if there is only one instance on the page
• Do this so your code is cleaner

Huh? Are the Internet cops going to pull me over and bust me if I use a class only once on a page? Does CSS behave differently if I use a class instead of an ID?

The fact of the matter is, using only classes for CSS just works better. You can define your classes semantically, even for layout elements that exist once on the page, and everything will work just fine. Better yet, if you change your mind later and need to use that class again, you don't have to go back and change IDs to classes on all your HTML elements and all of your #s to .s in your CSS. Just set the class and you're done.

Supposedly, the ID of an element takes precedence over its class (for some browsers), and I get that. But you can easily declare different CSS styles later in the cascade to overwrite values declared earlier.

The real reason to use IDs

JavaScript.

Because an ID can only appear once on a page, it's easy to bind to its associated element by using the document.getElementById method in your JavaScript.

Now you have a very good reason to use IDs in your HTML. When you are editing the page and see an element with an ID set, you know that it's going to be used in the JavaScript. This doesn't necessarily help you when you have multiples of the same element on the page, but in that case you will need to use an array or iterate through them somehow. If your site uses dynamically generated content (via PHP, for example), you can increment your IDs so that the JavaScript can easily iterate through them.

The ClearLake framework by Traction Systems can automatically increment your IDs for you using the autonumber switch on arrays. Or, if you use MagicEdit for your content management, using MagicRepeat will automatically increment your IDs for you.

So there you have it...

Classes are for CSS, and IDs are for JavaScript. Period.

An Update

Like many things in life, IDs are a bit more complicated than the above, but the general rule of thumb still applies. Since writing my little rant above, there are a number of other applications of IDs that I've recalled that take advantage of the fact that an ID appears only once on the page, and here are a couple of them:

Forms

For usability, form fields should have an associated label attached to them. This lets the user click on the label to set focus on the form element, or toggle the state of a checkbox or radio button, and screen readers use labels to identify various form fields as well. You can associate a label with a form by wrapping the form field itself in a label tag:

<label>First Name:< input type="text" name="firstName" /></label>

However, there are times when it's not convenient to wrap the label all the way around the form element. You want the label here and the form field there. To do this, you can associate a named label with the ID of a form element like so:

<label for="firstName>First Name:</label>
<input type="text" id="firstName" name="firstName" />

Named Anchors

Named anchors allow the designer to target a link to a particular part of a page. It could be the same page the visitor is currently on, or it could be a completely different page. A common use of this would be to have a "back to top" link for pages that require a lot of scrolling around. In order to accomplish this, you could set an ID on an element at the top of the page, then link to it using a special character in the hyperlink (the ubiquitous #):

<div class="header" id="top">...</div>
...
<a href="#top">Back to top</a>


Note that I could have just set the ID of the header to "header" and foregone the class declaration. I would have then used <a href="#header"> instead, but what if I want to change my design to scroll almost to the top but not quite? Since I have separated the styling from other site functionality by using classes for styling alone, I am now free to assign the "top" ID to pretty much anything I like.

So using classes alone for styling leaves the designer free to use IDs for things they were intended for, which was the whole point of this post anyway. Cheers!