Tangled in the Threads

Jon Udell, May 3, 2000

Why not WYSIWYG writing for the Web?

We're stuck in 1996. It's time to move on...to 1985.

In last week's column I mentioned Wiki and some of its derivatives, including ZWiki and TWiki. Wikis, of all flavors, are remarkable tools for collaborative writing on the Web. One of the reasons for this is the clever Wiki text formatter (see: Wiki, TWiki, ZWiki). It enables, among other wonderful capabilities, the automatic creation of hyperlinked pages. If this page were part of a Wiki web, I could create a new page in that web by typing: 

WikiFormattingExample

The rule is that a mixed-case word creates an implied hyperlink. When I save a Wiki page in which one of these appears for the first time, it'll be rendered like this: 

WikiFormattingExample?

The hyperlinked question mark in this example doesn't go anywhere, but in a real Wiki, the address behind the link would be something like: 

http://wiki-host/cgi/wiki?edit=WikiFormattingExample

On clicking the link, you're led to a newly-created page. There, you enter text according to the rules we'll explore more fully here in a moment, and click Save. Now, when you return to the original page, the phrase WikiFormattingExample has become a hyperlink to the page you just created.

This approach to hypertextual writing is beautifully simple and elegant, and the effects are quite magical.

What can you type on your newly-created Wiki page? Here are some examples:

you type Wiki renders
1  *list item 1

    *indented list item a

    *indented list item b

 *list item 2
  • list item 1

    • indented list item a

    • indented list item b

  • list item 2
2 This non-indented text renders in a proportional font. Now use indentation to introduce a monospaced code example:

  sillyFunction(arg1,arg2)
      { return 0; }

Back to normal font.

This non-indented text renders in a proportional font. Now use indentation to introduce a monospaced code example: 

  sillyFunction(arg1,arg2)
    { return 0; }

Back to normal font.

3 ''I can do '''Bold + Italic''' in Wiki!''
'''WOW!!!'''
It's
'''''so cool.''''' 		I can do Bold + Italic in Wiki! WOW!!! It's so cool.

You get the idea. Constructs that are easy to type in a line-oriented text editor (such as a browser's <TEXTAREA> widget) are automatically recognized and transformed into corresponding HTML markup.

Wiki doesn't really do away with markup, it just simplifies it. In example 1 above, the simplified rule for lists is to type a tab plus an asterisk for a first-level item, two tabs plus an asterisk for a second-level item, and so on. Unfortunately, most implementations of <TEXTAREA> don't allow tabbing. So the original Wiki offers to convert strings of three spaces to tabs. It'll also convert pairs of single quotes to italics, triplets of single quotes to bold, or even quintuplets of single quotes to bold italic, though you can't cross line boundaries with these constructs.

Oops. We're on a slippery slope here. Is it perhaps slightly easier to type: 

''I can do '''Bold + Italic''' in Wiki!''
'''WOW!!!'''
It's
'''''so cool.'''''

than to type: 

<i>I can do <b>Bold + Italic</b> in Wiki!</i>
<b>WOW!!!</b>
It's
<b><i>so cool.</i></b>

But there is not much simplification here, and it's offset by some drawbacks. Strings of single quotes aren't mnemonic in the way <i> and <b> are. And the former constructs care about line boundaries, whereas the latter don't.

Which approach is best? Neither, actually. Here's a radical idea. Suppose your editor enabled you to select regions of text, apply styles to them, and see the results instantly. Well of course we've all been writing this way for 15 years, using archaic, pre-Internet-era wordprocessors. But sadly, our high-tech Internet writing tools want us to learn and remember rules about typing triple-quotes and angle brackets.

HTML messaging: a flawed solution

Back in 1996, it looked (to me, anyway) as though HTML messaging was going to be a slam dunk. Communicator's Messenger and MSIE's Outlook Express arrived on the scene, both offering to transform the writing of mail and news from a line-oriented markup exercise into a WYSIWYG affair. The mail/news composer, in both products, was a good-enough HTML authoring tool -- not for fancy Web pages, but for the kinds of routine office documents that people write every day. You could interactively compose HTML documents that used tables, inline images (which could be dragged and dropped into place), hyperlinks (also draggable and droppable), fonts, and color. You couldn't do these things (yet) in email that might go to non-HTML readers, or appear on the USENET, but it looked like a great solution for intranets where everybody might reasonably be expected to be running one of the newfangled mail/news clients. After WYSIWYG messaging took hold on the intranet, it seemed that the Internet's public spaces would not long remain bastions of line-oriented ASCII.

OK, I was wrong. Today the 65-character line that governs composition of all email, and of most of the messages that I post to various forums, remains aggressively in force. I spend more time than I care to think about reformatting text to comply with this rule, and illustrating things using ASCII art: 

       +---+
       |   |
       | A |
       |   |
       +---+
      /     \
     /       \
   +---+    +---+
   |   |    |   |
   | B |    | C |
   |   |    |   |
   +---+    +---+

(Those plus signs really sharpen up the corners of those boxes, don't you think?)

This is nuts. I've been known to shout from the rooftops: "Fer cryin' out loud, just use the rich-text composer that comes with your browser." But I don't shout that so loudly any more because, in truth, those 1996-era HTML composers were only marginally competent, and they haven't improved at all since then. Catch-22: nobody's using them, so where's the incentive to fix them?

The situation is deeply ironic, when you stop to think about it. Most of us do most of our writing in a messaging client. And we do a lot of our reading on the Web. When we write messages, we have WYSIWYG composers at our disposal, but we can't use them because:

Meanwhile, on the Web, rich content is the norm. Everyone can read it. But when we write for the Web, we're presented with that tired old <TEXTAREA> widget.

Back to the future

Although Netscape took a lot of flak for introducing the notion of HTML messaging, I think it was an important step in the right direction. Somebody's got to put a stake in the ground, or we'll be typing ASCII art forever. But HTML messaging, introduced in 1996 and stagnant since then -- was at best a stopgap solution. Here's what I think we need now:

<RICHTEXTAREA></RICHTEXTAREA>

In a web form, this tag calls up a native cross-browser widget framed with the basic WYSIWYG controls for text alignment, font size, type style, color and emphasis, table and image manipulation. The <RICHTEXTAREA> widget is XML-savvy and will produce, minimally, well-formed and valid XHTML content plus a style sheet that tells how to display that content. Optionally, the XML output can be more strongly constrained to be an instance of a bug report, or an invitation, or a bibliography.

Let's not drag in namespaces and XML schemas and whatnot. Those are fine technologies, but I don't want to hold up the show waiting for them to be cooked, and we don't really need them to make this idea work. Let's just focus on the basics. The Web is a medium in which rich content is the norm, interactivity is on the rise, and a baseline standard tool for the production of rich content is nowhere in sight. I can sling markup with the best of them, and do every day, in emacs. The truth is, I'm highly productive that way. But I've learned not to expect the same of others. Some will master HTML, or Wiki-style markup, but most won't. So let's give them the WYSIWYG tool they want, deserve, and have taken for granted since 1985.

I'll confess to a secret agenda. I'm not only concerned about the needs of folks who want to communicate rich content on the Web. I'm equally interested in the needs of those of us who build the back-end systems that transmit, store, reorganize, search, and publish that content. If the <RICHTEXTAREA> widget can squirt out well-formed XML, we'll do wonders with it.

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads

Creative Commons License
This work is licensed under a Creative Commons License.