Instiki markup

ruby-talk
1

I’m not bagging Instiki. It’s cool. RedCloth, BlueCloth or RDoc are all very
well, but… can Instiki translate between them on-the-fly (i.e. at user
request - user A creates the page in RedCloth, but user B prefers
BlueCloth…)? When will Instiki have a WYSIWYG editing interface?

2

A Wiki with WYSIWYG is something I’d love to see. Something for
Flash, perhaps?

Gavin

···

On Sunday, May 23, 2004, 8:53:45 AM, Dave wrote:

I’m not bagging Instiki. It’s cool. RedCloth, BlueCloth or RDoc are all very
well, but… can Instiki translate between them on-the-fly (i.e. at user
request - user A creates the page in RedCloth, but user B prefers
BlueCloth…)? When will Instiki have a WYSIWYG editing interface?

3

I’m not bagging Instiki. It’s cool. RedCloth, BlueCloth or RDoc are
all very
well, but… can Instiki translate between them on-the-fly (i.e. at user
request - user A creates the page in RedCloth, but user B prefers
BlueCloth…)? When will Instiki have a WYSIWYG editing interface?

Making the markup language interchangeable would require limiting each
at the lowest common denominator. Exactly as database abstraction
layers are doing. I think that would be quite unfortunate for Textile
to be limited by what RDoc does. And unnecessary too. RDoc makes sense
for writing code documentation where as Textile has foot notes and
tables and CSS integration suitable for many other things (such as
writing a 100-paged bachelor’s project).

So. I wouldn’t hold my breath for a on-the-fly convertor.

WYSIWYG would indeed be nice, though. But as another commenter wrote,
it would need to output either Textile, Markdown, or RDoc code – not
HMTL.

···

–
David Heinemeier Hansson,
http://www.instiki.org/ – A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ – Web-based Project Management
http://www.loudthinking.com/ – Broadcasting Brain
http://www.nextangle.com/ – Development & Consulting Services

4

Well, could be done tomorrow, problem being that the WYSIWYG controls
that’s available generate raw HTML.

As for the translation, it’s not exactly a simple problem, you can’t
just ‘backtranslate’ HTML into Textile/Markdown/RDoc.

···

On Sun, May 23, 2004 at 12:33:00PM +0900, Gavin Sinclair wrote:

On Sunday, May 23, 2004, 8:53:45 AM, Dave wrote:

I’m not bagging Instiki. It’s cool. RedCloth, BlueCloth or RDoc are all very
well, but… can Instiki translate between them on-the-fly (i.e. at user
request - user A creates the page in RedCloth, but user B prefers
BlueCloth…)? When will Instiki have a WYSIWYG editing interface?

A Wiki with WYSIWYG is something I’d love to see. Something for
Flash, perhaps?

–
Thomas
beast@system-tnt.dk

5

Making the markup language interchangeable would require limiting each
at the lowest common denominator.

I don’t think this is necessary. Apps can exchange XML data that include
structures they know about and use, as well as structures that they don’t
know about. The key is they do not discard things they do no know about, but
pass it along to others.

In Instiki:
Suppose all input formats are converted into some internal XML dialect D.
Each markup format F would have a pair of translators: D->F and F->D.
Translators have to retain D-structures that do not translate to/from F. So
when I am editing in Textile I might see the raw-XML equivalent of some RDoc
structure.

D itself should be extensible. So my format, F, could include semantic
markup like and .

HTML presentation should be done by CSS on the underlying representation D,
by default. Assuming semantic markup is allowed in the input formats F (e.g.
), the presentation could take advantage of this with

,
, fold/unfold, mapping to tables via CSS, etc.

Browser-based editing could be based on the structure (add/delete/edit
nodes), in addition to the usual text-area based editing via some markup F.

Some well-formedness rules may have to be more carefully checked in
translations. But other than this it should work pretty well.

6

Some well-formedness rules may have to be more carefully checked in
translations. But other than this it should work pretty well.

I fail to see the general usefulness of conversion between formats if
only a subset of the capabilities can be converted. If my document
written in Textile relies on footnotes then a lossy conversion to RDoc
without the footnotes would make little sense. The lossy conversion
leads to a corrupt product.

That is unless someone would go about bringing all the markup languages
up to the highest common denominator (HCD) – either by direct
alteration of the language or by work-arounds (representing footnotes
in RDoc in parenteses behind the referenced word or sentence).

But all this is missing the point. The reason different markup
languages exist is to cater for different applications. Textile is good
for integrating with HTML (thanks to CSS hooks among other things),
RDoc is already the language for documenting Ruby code.

If conversions are to work to the HCD, then the differences between the
languages are reduced to somewhat meaningless syntaxes.

Anyway, this seems to be a much more philosophical than pragmatic
discussion. The usage benefit of switching between markup languages on
the fly seems incredibly small compared to the amount of work required
to convert at the HCD.

But I am in no way going to argue or refuse a patch from someone
committed to keep all supported markup languages supported by a HCD
approach. Bring it on! :slight_smile:

···

–
David Heinemeier Hansson,
http://www.instiki.org/ – A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ – Web-based Project Management
http://www.loudthinking.com/ – Broadcasting Brain
http://www.nextangle.com/ – Development & Consulting Services

7

David, of course you’re right that for a RedCloth-written document to be
displayed in RDoc, it must necessarily lose features (or add features to
RDoc, which would then cease to be RDoc). But if the document is stored in a
dialect (Its Me’s D) with a featureset that is a superset of the union of
the features of RedCloth and RDoc, an editing control could conceivably
(just) degrade untranslatable features into plain text, but retain the
markup behind the scenes.

I think WYSIWYG is better and more important, though.

As Thomas Fini Hansen notes, existing editing controls generate HTML.

(Back-translation to Textile/Markdown/RDoc would be possible if the HTML
generated therefrom was identified somehow.)

But what about having a wiki document written in pure HTML? The only
important feature that’s obvious to me that a wiki document needs that HTML
doesn’t already provide is WikiWords; I’d propose you do something like Wiki word. This would allow existing HTML editing
controls (e.g. FCKEdit, htmlArea) to be easily leveraged for wiki use.

OK, I don’t like that I’m proposing a whole new wiki document format, but
HTML is already more standardised and more commonly used than any of the
others.

The idea of WYSIWYG editing could be applied to, say, RedCloth/Textile quite
easily, too, Easily conceptually; it’s obviously going to be a bigger change
to an HTML editing control.

I like Its Me’s suggestion of structure-based editing as well, but I don’t
know of any existing tools to do that with HTML (although I do remember
seeing a Microsoft XML editor demo in HTML, which could be close, but
probably entirely unportable).

8

But what about having a wiki document written in pure HTML? The only
important feature that’s obvious to me that a wiki document needs that
HTML
doesn’t already provide is WikiWords; I’d propose you do something
like Wiki word. This would allow existing HTML editing
controls (e.g. FCKEdit, htmlArea) to be easily leveraged for wiki use.

This could work. The pure HTML would just be another markup language,
just like Textile, Markdown, or RDoc. And either the standard rules for
[[wiki word]] and WikiWords are just retained (so people write that
manually) or they could be processed as you say through a class.

It’s obvious that this approach would require all users on a HTML-only
wiki to use the WYSIWYG control. But that might be just fine for some
organisations.

Please do have a stab at such an implementation.

···

–
David Heinemeier Hansson,
http://www.instiki.org/ – A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ – Web-based Project Management
http://www.loudthinking.com/ – Broadcasting Brain
http://www.nextangle.com/ – Development & Consulting Services

9

Anybody have a favourite web-based WYSIWYG HTML editor?

“David Heinemeier Hansson” david@loudthinking.com wrote in message
news:13DC7DF9-AD69-11D8-A2EA-000A958E6254@loudthinking.com…

···

But what about having a wiki document written in pure HTML?
[…] This would allow existing HTML editing
controls (e.g. FCKEdit, htmlArea) to be easily leveraged for wiki use.

This could work. The pure HTML would just be another markup language,
just like Textile, Markdown, or RDoc. And either the standard rules for
[[wiki word]] and WikiWords are just retained (so people write that
manually) or they could be processed as you say through a class.

It’s obvious that this approach would require all users on a HTML-only
wiki to use the WYSIWYG control. But that might be just fine for some
organisations.

Please do have a stab at such an implementation.

10

I’m trying to figure out Instiki. It’s a nice piece of work.

But what would be the best way to have return a javascript file, ideally
shared between webs? Also being able to return other files from that
subdirectory may be required.

eg:

/htmlarea/htmlarea.js

or is this better?
/my_wiki/htmlarea/htmlarea.js

Cheers,
Dave

“David Heinemeier Hansson” david@loudthinking.com wrote in message
news:13DC7DF9-AD69-11D8-A2EA-000A958E6254@loudthinking.com…

···

But what about having a wiki document written in pure HTML? The only
important feature that’s obvious to me that a wiki document needs that
HTML
doesn’t already provide is WikiWords; I’d propose you do something
like Wiki word. This would allow existing HTML editing
controls (e.g. FCKEdit, htmlArea) to be easily leveraged for wiki use.

This could work. The pure HTML would just be another markup language,
just like Textile, Markdown, or RDoc. And either the standard rules for
[[wiki word]] and WikiWords are just retained (so people write that
manually) or they could be processed as you say through a class.

It’s obvious that this approach would require all users on a HTML-only
wiki to use the WYSIWYG control. But that might be just fine for some
organisations.

Please do have a stab at such an implementation.

David Heinemeier Hansson,
http://www.instiki.org/ – A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ – Web-based Project Management
http://www.loudthinking.com/ – Broadcasting Brain
http://www.nextangle.com/ – Development & Consulting Services