Writing tools for the web

We’ve come so far, and yet, we have so much farther to go.

When I set up my first website, all my HTML coding was manual. Creating a new page meant opening up a copy of an empty web-page template I had created, writing the page, saving it, uploading it by FTP, editing my local copies of any other pages I wanted to link to it, saving them, and uploading them (and any graphics that might be involved). Using Japanese at all was fraught with peril, because there wasn’t a single browser that could handle the three prevailing encoding methods for Japanese (Shift-JIS, New JIS, EUC). There were some primitive web tools that allowed you to edit pages directly on the server via the web browser, but the browser provided a miserable interface, and I didn’t have the cash or the technical chops to install one of these.

Today, we’ve got content-management systems and blogs that handle most of these tasks. Modern browsers have tolerable editing interfaces and are vastly smarter about international characters (and in any case, we’ve got Unicode). Right now I’m typing this in a small program that runs on my computer and talks to my blog’s software to upload my posts.

But some people want more. They want an editing tool that gives them smooth control over HTML and CSS, and somehow gets out of their way to make this all transparent. Something like Microsoft Word for the web. Well, that’s a poor analogy, because Word is terribly intrusive. Like how it goes and creates bulleted lists for you when maybe you don’t want one (unless you go to considerable trouble to get Word to cut it out). Interestingly this kind of thing is considered a useful feature in blogging tools, which may say something about the state of editing tools, or the difficulty of writing HTML. I’m not sure.

Back in the bad old days of personal computing, word-processing for paper output was about as bad as writing HTML is today: you had to type tags or special codes to make text bold, italicized, or centered. With the exception of some hardcore XyWrite enthusiasts, WYSIWYG was acclaimed a great leap forward for word-processors.

So great has been WYSIWYG’s hold on our imagination that it is promoted as a worthy format for web-writing tools. It ain’t. Although my handy-dandy blogging tool will do a tolerable job of wrapping <p> tags around my paragraphs, it can’t do much more than that, so there’s clearly room for improvement. But how do you deal with hyperlinks wizzywiggily? Or the clever abbreviation above, that shows its full expansion when you hover over it (in a decent browser)? There’s no way. HTML is not presentational, it’s structural. You need a way to show the structure of the document as you write. For presentation, we’ve got CSS, which determines the presentation of content for different media: screen, paper, even speech-synthesis. In the land of print, you might have a rule that document titles are always 24-point bold and centered. In the land of HTML, all you know is that a chunk of text tagged as <h1> is at the top of the document hierarchy (and there’s room for dispute on that). That same chunk of text could have completely different forms of presentation because HTML is not tied to any form of output; it contains different forms of meta-data that will often be presented identically (but might be useful to search engines), and contains some that simply isn’t meant to be viewed by humans.

So we’ve got to deal with HTML, content, and CSS. I can imagine a writing program that lays things out like this:

Tag Content CSS
h1 Here is a heading Screen
font-family: helvetica;
color: #600;
font-size: 18px;
Print
font-family: helvetica;
text-align: center;
font-size: 18pt;
p Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Praesent consequat, nibh at aliquam convallis, sem arcu sodales mauris, et sagittis risus wisi ut dolor.. default

Perhaps there would be popup menus in the Tag and CSS columns, or perhaps some intelligent prediction that writers can override (when we get intelligent prediction in the Content column, watch out).

Of course, even this is still too simplistic. In terms of HTML handling, this model is OK for block elements, but does nothing for inline elements. Dealing with nested elements could be tricky. For CSS, it gets very hairy. CSS is complicated: styles can reside in the tag, in the head of the document, and in other documents, all pulled together in different ways. Styles may apply to a tag universally or contextually. So this putative tool would need to analyze the document structure to determine which contextual CSS rules to show. And if the author serves pages dynamically , or uses dynamic includes to assemble a page from multiple fragments (as I do), it will need to take that into account.

I don’t see an easy way out. A program that is easy to use and allows fine-grained control and generates smart, well-formed HTML and CSS will be a serious challenge for interface designers and coders.

2 thoughts on “Writing tools for the web”

  1. WYSIWYG for things like wordpressing are essential, i couldn’t live without that. but for the web? their awful, all of them. for wordprocessing i don’t need to know what code it makes and needs to read itself to get the page i want. but for the web WYSIWYG editors (like dreamweaver and frontpage) just don’t cut it, at least not for serious developers.

    IMO tools for the web should just make updates pages a little easier, such as news publishers, but you should still need to write some html for the post.

  2. I agree that the existing WYSIWYG tools for web authors are not a good idea. I don’t agree that everyone should be required to write HTML in order to just update their blog, for example.

    My point is that a third way should be possible: a tool that encourages an understanding of how HTML works and reveals its structure without forcing you to write tags or for that matter, read them inline (both of which I find interrupt the flow). But it won’t be easy.

    for wordprocessing i don’t need to know what code it makes and needs to read itself to get the page i want

    The funny thing is, you want control over the code in HTML but not print; there are people (TeX fans) who want control over the code in print, too. And more power to them.

Comments are closed.