Re: WWWWW Notes

Steve Heaney (Steve.Heaney@delft.sgp.slb.com)
Fri, 13 Aug 1993 13:10:51 +0200


Marc Andreessen writes:
> Bob Stayton writes:
> > - The Xmosaic display widget writer was there, and he tried to do an
> > editible version. The main barrier seems to be editing structured
> > documents. It is hard to define a good WYSIWYG interface for that
> > because users aren't used to structure, and visual cues to indicate
> > what element the cursor is in are important (but break the WYSIWYG).
>
> This is the clincher. There can never be such a thing as a WYSIWYG
> HTML editor, due to the nature of HTML. The editor has to not only be
> a structured text editor but has to make it clear to the user what's
> going on in the structured text, and not let things break, but still
> open up all the possibilities, without being more confusing than
> simply writing HTML by hand. This is not easy. I'm not even sure if
> it's possible. I tried to come up with a GUI design for such an
> editor and couldn't.
>

What is it about the nature of HTML which makes WYSIWYG impossible?

Maybe I misunderstand what you expect of a WYSIWYG editor, but there
are several commercial SGML editing packages which would claim to
be (and are to my way of thinking) WYSIWYG.

The one I'm familiar with allows markup in a few different ways.

o A pull-down menu of all of the tags is available (which can be
configured to group related elements) and tags which are not valid
in context are greyed out.
o A pinable popup window is generated which lists alphabetically all of
the valid tags in context.
o Striking the return key enters a new tag if the context is unambiguous
and depending on user defined rules.
i.e. return in a paragraph creates another paragraph container.
return in a list element creates another list element.

The user can toggle between states where the tags are displayed or not.
Without tags displayed, it is to all intents and purposes WYSIWYG.

> I think it's telling that lack of an editor hasn't been a showstopper
> -- WWW is growing much faster than other network tools regardless.
> (Yes, I agree an editor would be *useful*; that's not my point.)
>

HTML+ will be a different kettle of fish however, given the size
of its vocabulary (tags + attributes). If, as I hope, the idea of
supporting non-conformant documents is dropped some sort of validating
editor will be required, whether full WYSIWYG or not.

> I also think conversion tools will, in the long run, be more useful
> than an editor. Why? Any editor produced in the WWW environment and
> given away is simply not going to be able to compare with standard
> commercial editors. We are not Microsoft (none of us). Also, HTML
> does not make a good base document format; I find it hard to believe
> that publishers, for example, are going to be using it as their base
> format, ever. A converter that capitalizes on a good preexisting
> format (e.g. RTF) and delivers good HTML as an output format for
> networked information distribution is much more useful in such cases.
>

Anything that broadens the options has to be a good thing. Converters
are a good way of getting documents quickly into the Web.

However, I think (picking up on Nat's comments in http://www.vuw.ac.nz/\
non-local/gnat/converters.html) that the HTML+ DTD should stand on its own
feet as a usable DTD with "broad appeal". A common DTD encoding semantic
information is obviously important for document exchange and reuse, and so
we should strive to achieve this however difficult the task may seem.

A DTD describing an "abstract presentation information" (which Nathan
suggests) is no more or less than _another_ presentation format. Surely
we can aim higher that that.

> As usual, my opinions only...
>
> Marc
>
>

Steve.