Re: [sfWiki-devel] status report

[Iain S. <iai...@ya...>]

--- "Todd L. Miller" <tm...@ha...> wrote:
> > I think you should approach this in the opposite direction.
> 
> 	I wanted to support HTML in the Wiki because it's going to be
> easier for some people to write the HTML than learn the
> WikiMarkup.  TWiki says it supports 'most' HTML tags, though I didn't
> find a full list.

Agreed.  But it opens up security holes (especially on a php powered
site).

> > Ideally, wiki markups and no html should be use.  Realistically,
> > wiki markups and some limited set of html will be needed.
> 
> 	Actually, we could almost certainly get away with no HTML markup
> at all; there's nothing intrinsically difficult about it.  It's just
> that
> past a certain point, certain features make more sense in HTML, because
> they're advanced enough that the author is likely to know the HTML to
> create them.  However, I suspect that most of these features are
> potential
> security holes :)

Yup.  The wiki is collaborative first.  Hence the simple wiki markups and
simple text (wiki markups should look a lot like ascii formatting).  IMHO,
you should always sacrifice features for ease of use, speed, and
communication when dealing with a wiki.  The wiki is all about content. 
Complex formatting and 'html tricks' really don't have much of a place in
a wiki.  If you could come up with a logical, simple wiki markup for
images and linking (where the display text is not the same as the link and
for same page anchors) I'd say to completely eliminate html.

> 	I'll give it some more thought, but before I do -- I allowed
> nesting of bold/italic/fixed-font, which it doesn't look like the normal
> wiki does.  There a reason for that?

Yup.  The way it does its parsing.  The original perl wiki code is a bunch
of regex with very simple substitution rules.  As such, its not a full
blown parser, and can't handle some markups well without a lot of painful
contortions.  Once again, simplicity ruled (although perhaps for speed of
implementation rather than as a design goal) so nesting is simply not
supported.  I'd probably avoid supporting nesting simply because it can
possibly have unintended consequences...  Of course, since its already
implemented, I guess I'd leave it in.  :)

Note: I know I don't say it often enough, but I really do appreciate the
time you're putting into this.

-iain

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/