[Pmwiki-users] Markup

[Patrick R. Michaud]

On Thu, Aug 07, 2003 at 09:23:17PM +0200, Massimiliano Mirra wrote:
> This had me wonder: is wiki 
> a simplified markup or a transparent, implicit markup?  
> [...]
> I had not considered it before but more or less
> unconsciouly assumed that wiki text had to be transparent.  Maybe this
> is because I am so fond of Emacs and text editing that I mostly see
> HTML rendering as an add-on. :-) I would really like to hear others'
> opinion (especially Patrick's since this obviously sets the direction
> for a wiki).

Sure, I'm always glad to offer my opinion--but on this topic my opinion
may have a tendency to run a bit long. :-)  Actually, for almost a year 
I've been wanting to write an article, possibly for publication somewhere, 
about the role of wikis and markup languages (among other topics).  But so far
I just haven't found myself in the right mind-frame to do it.  In the meantime,
here are a few snippets:

I'm not sure I could classify wiki as being either "simplified markup"
or "transparent markup".  Certainly it has aspects of both.  In a lot
of ways wiki markup is "transparent" in the sense that someone can generally
read the markup version of a document and understand it as well as they can
the rendered version.  Conversely, someone can write something in wiki markup
and the formatted results will generally look pretty close to what they've 
written.  HTML fails miserably at transparency, and XML (XHTML) is even worse.  

However, wiki markup is not completely transparent, since we have things
such as {{free links}} and embedded images and the like.  Complete 
transparency gets into the realm of WYSIWYG systems.  However, over the 
past year I've been developing a personal thesis that basically says 
(1) that WYSIWYG is possible only when the editing software has complete 
control over the rendered output, (2) that this only happens in 
specialized applications and contexts, and (3) that collaborative web 
authoring is not one of these contexts given current technologies, 
standards, and trends.  

People like to tout WYSIWYG editors as somehow superior because authors 
don't see or have to know about markup.  I'm not convinced this is always 
a good thing--sometimes the markup is more usable and understandable 
than trying to guess what might happening inside the system's black box 
because the underlying markup is hidden (something I frequently find myself 
doing when using WYSIWYG programs such as Microsoft Word).  I'm always
reminded of Donald Norman's "The Design of Everyday Things", in which
he repeatedly says that good design comes from making invisible 
things visible, not vice-versa.

And people aren't really adverse to using or seeing markup; we actually 
use visible markup all of the time!  Periods, commas, quotation marks, 
parentheses, capitalizing words in titles and at the beginnings of 
sentences, placing blank lines between paragraphs--these are all, in 
fact, visible language markup.  We're just so used to seeing and using them 
that we don't find them intrusive--we read and write them naturally.
(Well, most of us do. :-)

So, having visible markup isn't always a bad thing--it's only bad when
it interferes with our ability to create and/or understand a
document.  And transparent markup isn't always a good thing--it's bad
when there's not a clear mapping between the markup text and the output,
or when it would be easier to understand by using markup.  And to extend 
this into the web realm a bit further, I think HTML and XHTML fail for 
collaborative authorship of documents because the markup is too 
complex/intrusive for natural language writing, and WYSIWYG systems 
fail because the markup is too hidden and provides a largely incomplete 
mapping between source document and output results.

So, wikis in general, and PmWiki in particular, try to develop markup
sequences that are reasonable extensions of the markup we're already used
to using when authoring text documents, and that can be quickly grasped
and used by people who may not understand the underlying rendering
language (i.e., HTML, CSS, and XHTML).  To return to the original
question, wikis provide a "simplified and more transparent markup" from
HTML.

However, there's an important aspect of wiki markup languages that the
question of simplicity and transparency does not address, and that is 
the fact that PmWiki makes it possible to extend the markup language
to include new features.  So, if your application could use a markup
sequence to represent some specialized feature, it's relatively
easy to add it (and a lot of PmWiki administrators take advantage of
this).

I think lack of extensibility is another huge shortcoming of HTML--there's 
no easy way to create new sequences in terms of existing ones.  The same 
is largely true for XHTML:  even though it's supposed to be "eXtensible", 
one cannot simply aggregate existing markup together to make new ones,
instead one must know about DTDs, XLST stylesheets, CSS, and a bunch of 
other things that are in entirely different languages.  HTML and XHTML
are analogous to programming languages in which there's no capability
to create user-defined functions--something that we supposedly outgrew
in the late 1970s.

So, to me the point of wiki markup is not to be faithful to a principle
of being a simplified markup or a transparent markup, but rather to 
strive towards whatever is most "natural" for authors to create web
pages.  Markup should be transparent or visible according to whatever 
will make the most sense to authors.  And beyond that, since we're 
talking about something that is ultimately a language for communicating
among a group of people, there should be mechanisms for extending the 
markup to support specialized communications within the group.

How's that?  :-)

Pm